This Month in React


  • (00:00) - This Month In React - September 2025 (SM)
  • (00:52) - New releases
  • (00:54) - [TanStack Start 1.0 RC!](https://tanstack.com/blog/announcing-tanstack-start-v1)
  • (01:13) - [`react-window` 2.0 rewrite](https://react-window.vercel.app/)
  • (01:44) - [Apollo Client 4.0](https://www.apollographql.com/blog/announcing-apollo-client-4-0)
  • (01:59) - [Redux Toolkit 2.9.0](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.9.0)
  • (02:47) - Main Content
  • (02:52) - [React 19.2 coming soon?](https://bsky.app/profile/ricky.fm/post/3lzt6yvs6o22r)
  • (03:24) - [ in canary, with docs](https://react.dev/reference/react/Activity)
  • (07:18) - [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](https://react.dev/reference/react/useEffectEvent)
  • (15:47) - [Compiler inferring function names](https://github.com/facebook/react/pull/34410)
  • (16:08) - [Docs for `eslint-plugin-react-hooks`](https://react.dev/reference/eslint-plugin-react-hooks), including rules and compiler issues
  • (17:15) - [React Native 1.0 on the horizon](https://youtu.be/GPtopk4y2LI?si=JoZVprPW33szn-6D)
  • (22:02) - [“React Won by Default – And It's Killing Frontend Innovation”](https://www.lorenstew.art/blog/react-won-by-default/)
  • (22:18) - Inevitable [HN argument](https://news.ycombinator.com/item?shownew&id=45252715)
  • (27:54) - [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
  • (33:44) - [React Router RSC framework mode preview](https://remix.run/blog/rsc-framework-mode-preview)
  • (34:36) - also [middleware is now stable](https://remix.run/blog/middleware)
  • (34:44) - 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](https://bsky.app/profile/ebey.bsky.social/post/3lyf6vixick26)
  • (35:55) - 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
  • (39:47) - [npm package maintainer Qix](https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack)
  • (39:48) - [CrowdStrike npm Packages](https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages)
  • (40:16) - [GitHub Actions npm Token Theft](https://socket.dev/blog/nx-supply-chain-attack-investigation-github-actions-workflow-exploit)
  • (41:01) - [GitHub response](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/)
  • (42:00) - ⚡ Lightning round ⚡
  • (42:03) - [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](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`](https://www.bocoup.com/blog/the-webs-most-tolerated-feature)
  • (43:56) - [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 upload/download progress](https://jakearchibald.com/2025/fetch-streams-not-for-progress/)
  • (45:40) - [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](https://addyo.substack.com/p/how-modern-browsers-work)
  • (46:32) - [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](https://bun.com/blog/behind-the-scenes-of-bun-install)
  • (49:23) - [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`](https://www.patron.com/blog/post/vite-ssr-getstaticprops-replacement/)
  • (50:11) - [Dominic Gannaway’s new framework Ripple](https://github.com/trueadm/ripple)
  • (50:35) - [Remix v3: MJ hints “iframe-like async primitives”](https://x.com/mjackson/status/1971816432427298951)
  • (51:57) - [React Native RFC to remove Old Architecture](https://github.com/react-native-community/discussions-and-proposals/pull/929)
  • (52:28) - [Cloudflare’s new “Cap’n Web” RPC; GraphQL alternative?](https://blog.cloudflare.com/capnweb-javascript-rpc-library/)
  • (55:26) - [Expo UI: Building SwiftUI apps](https://docs.expo.dev/guides/expo-ui-swift-ui/)
  • (55:57) - [TanStack DB: An interactive guide](https://frontendatscale.com/blog/tanstack-db/)
  • (56:21) - [TS 6.0: may switch to `strict` options by default](https://github.com/microsoft/TypeScript/issues/62333)
  • (57:28) - [Shopify’s RN New Architecture migration](https://shopify.engineering/react-native-new-architecture)
  • (57:42) - [The Bloat of Edge-Case First Libraries](https://43081j.com/2025/09/bloat-of-edge-case-libraries)
  • (58:51) - Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
  • (58:53) - [React Alicante](https://reactalicante.es/) Oct 2-4
  • (59:13) - [React Conf is back, Oct 7-8](https://bsky.app/profile/react.dev/post/3lmcp4mhmfk2l) Las Vegas, NV, USA
  • (59:29) - [Remix Jam](https://remix.run/jam/2025), Oct 10, Toronto ON, CA
  • (59:43) - [ViteConf](https://viteconf.amsterdam/) Oct 9-10 Amsterdam, Netherlands
  • (59:52) - [JSConf North America](https://events.linuxfoundation.org/jsconf-north-america/) Oct 14-16 Chesapeake Bay, MD, USA
  • (01:00:03) - [JSConf Chile](https://jsconf.cl/) Oct 24-25 Santiago, Chile
  • (01:00:10) - [React Native London](https://www.reactnativelondon.co.uk/) Oct 30-31
  • (01:00:22) - [React India](https://www.reactindia.io/) Oct 31 Nov 1 Goa, India
  • (01:00:26) - [Wey Wey Web](https://www.weyweyweb.com/) Nov 17-18 Malaga, Spain
  • (01:00:39) - [React Summit](https://reactsummit.us/) Nov 18-21 New York, NY, USA
  • (01:00:48) - [React Advanced](https://reactadvanced.com/) Nov 28th, London UK
  • (01:01:08) - Outro

Creators and Guests

Host
Mark Erikson
An engineer maintaining Redux and Redux Toolkit, working at Replay.io to make smarter AI chat bots and debuggers using time travel.
Host
Mo
Head of Mobile at Theodo, a software consultancy that does native app development for iOS and Android
Producer
Carl Vitullo
Solopreneur just vibing, posts are probably bullshit. Community lead at Reactiflux, the largest chat community of React professionals.

What is This Month in React?

How busy professionals stay on top of the React ecosystem. We give you a 1 hour recap of the latest news and nuance in React's development and ecosystem, upcoming conferences, and open source releases. New episodes the first week of every month, with live recordings on the last Wednesday of every month in the Reactiflux stage.

Hosted Mark Erikson (Redux maintainer), Carl Vitullo (startup veteran), and Mo Khazali (head of mobile at Theodo). See something for us? Post to #tech-reads-and-news

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.

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.

Carl: Yeah, you did a live stream on that.

That was cool.

Mark: Yeah, that was a lot of fun.

Mo: And my name is Mo.

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.

Carl: Yeah, more on that later.

Let's jump into some new releases.

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.

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.

Carl: Oh, that's nice.

Okay.

Yeah, and react window is
efficiently rendering large lists.

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.

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.

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.

Carl: Okay.

Yeah.

Not too many new releases for open
source libraries this month, I guess.

Mark: Well there, there
probably were a few more.

We just didn't collect them.

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.

It feels like.

Cool though.

Let's go into our main content.

Can you tell us a bit about React updates?

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.

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.

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.

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.

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.

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.

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.

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.

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.

Yeah.

But I, I don't entirely buy that myself.

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.

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.

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.

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.

But we envision some possible
additional modes for this down the road.

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.

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.

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.

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.

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.

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.

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?

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,

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.

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

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.

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.

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.

So,

Carl: okay.

That's probably long enough
talking about activity though.

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.

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.

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.

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.

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.

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.

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.

Carl: Right.

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.

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.

Carl: Yeah.

Okay.

That makes sense.

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.

That's quite a set of constraints.

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.

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.

Carl: Interesting.

Interesting.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Carl: That is really exciting.

That's a long time towards 1.0.

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.

Mark: Even just waiting for
the new architecture to be the

default, I think was a big thing.

Mm-hmm.

Yeah, definitely.

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.

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.

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.

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.

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.

Carl: Cool.

Drama post?

Mark: Drama post.

Carl: Yeah, so there was a recent
post called React Won by default and

it's killing front end innovation.

Mark: To some extent.

There's nothing new in this post.

People have been making
complaints about this for years.

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.

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?

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.

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.

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.

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.

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.

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.

I think he's actually
got a pretty good point.

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.

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.

Mark: Daniel Switz.

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.

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.

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.

I guess that's what I,
what I have to say there.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

And so I genuinely happy he's engaging.

I would just love to see that
material written up longer term.

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.

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.

I, I'll throw that gauntlet down,
like that is an achievable thing

that I am probably not gonna do.

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.

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.

Mark: Love the idea.

Alright, moving right along.

A few different updates related
to server components this month.

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.

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.

And especially when it's built into
something as widely used as React router.

Carl: Yep.

Love that.

Mark: They also announced that
React router now has stable

middleware support as well.

Your routes can now have middleware.

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.

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.

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.

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.

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.

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.

So it's wow, throwback.

That's a long time.

Alright, little bit of a roundup on.

Vulnerabilities and
security incidents on MPM.

There's been a lot this month.

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.

It's, it's been pretty
bad out there folks.

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.

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.

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.

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.

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.

That's just a miss.

Like that was just luck, that
it wasn't worse than it was.

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 tiny color
and a bunch of CrowdStrike packages.

Yeah.

I don't know the extent of like what
sites got hit because of that compromise.

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.

Carl: Yeah.

Oh, I was just reading this one actually.

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.

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.

I don't understand how they're
still operating successfully.

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.

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.

Interesting.

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.

So dunno how, dunno what you
do about that specifically.

But, okay.

Let's hop into our lightning round.

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.

Like why would you want to, I don't
know, but apparently they actually

made this work and I love it.

Carl: That is insanity, and I also love
it spiritually similar to Doom running

in TypeScript types, just for no reason.

Yep.

Love.

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.

Oops.

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.

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.

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.

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.

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.

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.

Mark: And it was long too.

It was long.

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.

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.

So, great summary.

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.

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.

Although there's discussion
of adding some new options and

callbacks to fetch that might
accurately handle that at some point.

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?

And basically it's because people rate
bad code or either intentionally or

unintentionally that can do bad things.

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.

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.

One that I like here.

I like seeing Vercel and Biome
collaborated on stress testing, biomes

new, no floating promises lint rule.

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.

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.

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.

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.

Mark: Mm-hmm.

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.

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?

Like construct?

It's a good read.

It's a good deep dive.

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.

Carl: Oh, it is, Love Dmitri.

Love that.

There is a good deep dive here into
Bun Install and how it's so fast.

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.

Mark: I think Lydia Halley wrote that
one actually very well written post.

Lot of detail.

Carl: Wait, was she on React?

Mark: I believe she was working for
Vercel and left, and I think she

actually just joined Bun as a DevRel.

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

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.

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.

So if you're still work, still
using style components, you may

want to take a look at that.

Also saw a nice little post that
talked about building your own

get static props alike equivalent
if you're using Vite for SSR.

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.

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.

And oh, the plan is to actually
show stuff off at Remix Jam, which

I think is coming up next month.

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.

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.

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.

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.

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.

Mark: So CloudFlare announced a new tool
called Cap'n Web, which is a RPC system

meant for browsers and web servers.

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.

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.

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.

Carl: Interesting.

And also, I'll shout out.

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?

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.

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.

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.

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.

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.

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.

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.

Carl: TypeScript version six may
switch to strict options by default.

This is,

Mark: hallelujah.

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.

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.

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.

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.

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.

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.

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.

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.

Cool.

Let's talk about some conferences.

We have in like three days, two days.

React Alicante in Spain,
October 2nd through fourth.

Mark: I will be speaking there.

I'm flying out on Wednesday.

Carl: Woo.

And then you're fly.

And then you're flying

Mark: all the back and then flying
all the way back across, across

the world for to attend React Conf.

Carl: Yep.

I'll be there too.

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.

Then a couple days after React
Conf, Remix is doing their own

conference in Toronto, the Remix Jam.

So yeah, maybe.

We'll, we will see.

It'll be interesting to see
what they come out with.

Yeah, I'm curious.

Yeah.

Anyway, coincident with that,
ViteConf is happening October

9th and 10th in Amsterdam.

That'll be cool.

Love to see what they come out with.

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,

and they're also doing re JSConf Chile,
October 24th and 25th in Santiago, Chile.

We've also got, after that React
Native London, October 30th and 31st,

Mark: and Mo runs that, so you should
totally be there and support him

Carl: after that, there's React
India October 31st and November 1st,

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.

And then we've got React Summit happening
in New York, November 18th through 21st.

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.

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.

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.

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.

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.

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.