This Month in React

Full transcript at Reactiflux

Main Content

⚡ Lightning round ⚡


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: 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.

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.

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.

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.

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.

Carl: Yeah.

A leader in the React Native community.

I'd even go so far as to say,

Mo: I would say member Member
is, and member humility is good.

Carl: yes it is.

Okay, fine.

A steward.

Mo: I, I appreciate you, Carl, as always.

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

Mark: doing.

Redx,

Carl: Yes.

Mark: or, or, or equivalent of Redx.

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.

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.

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.

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.

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.

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.

Carl: Yeah.

And I believe they gave a pretty big
demo of the dev tools at React Conf.

Is that right?

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.

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

Mo: some tools were really painful
before these new dev tools like

Flipper, the React Native support got
deprecated, was notoriously difficult

Mark: use.

So

Mo: this is a move in the right direction.

Obviously.

There was a, there was much demand for it.

Carl: very cool.

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.

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.

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.

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.

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.

I'll see what he does here.

He's got good opinions about
developer experience and the

contracts we interact with.

Yeah,

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.

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.

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.

Yes.

Okay.

Let's get into our main content,
starting with can anyone guess it's

gonna be the React2Shell vulnerability?

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.

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.

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.

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.

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.

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?

Mark: I, think It I I think
that was Log2Shell maybe.

Mo: was like that was the last

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.

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.

Carl: Yeah, You get one of these

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.

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.

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.

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.

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.

I don't, I don't believe they've
commented publicly about what exact

Mark: I, I think, I think that one may
have been somewhat related to Elle's

application firewall rules that they, that

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.

Mark: Mm-hmm.

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.

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.

And that was, do you remember
what the code name for that was?

Mark?

Mark: That was fiber.

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.

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.

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.

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.

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.

And next thing the attacker is
running arbitrary JavaScript code

within the context of your server.

And then very bad things happen.

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.

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.

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.

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.

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.

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.

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

Mark: So , this happened
in what, December?

11th ish, I think.

Carl: Yeah.

second pair of
vulnerabilities was the 11th.

First one was the third.

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.

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.

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.

CloudFlare put out a post detailing.

"Yeah. We're, seeing this getting
used in a lot of penetration scans."

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.

, 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.

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.

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.

Okay.

Some tech analysis.

I guess I did sort of an abstract tech
analysis, but let's get deeper in.

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.

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.

Carl: Yeah, so I guess the vulnerability
here is a carefully crafted promise

des serialization and a function eval.

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.

Mark: It's not the eval keyword, but
new function and, and passing in a, a

string is essentially the same thing.

Carl: Slightly different semantics,
but essentially the same thing.

Executing untrusted code.

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.

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

Carl: check

Mark: around that.

And so there were a couple
very good breakdowns.

Guillermo Rauch, CEO of Vercel
posted a, a tweet where he went

into some detail on what the actual
vulnerability issue itself was.

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.

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

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."

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.

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.

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.

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.

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.

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.

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.

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.

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."

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.

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.

I agree with you that the
way the phrasing here and the

defensiveness does not look ideal.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Mark: And are all the mitigation
steps going forward to improve our

process and make sure that this set
of problems never happens again.

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.

Carl: Or delegate to a PR team.

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.

Carl: Can't avoid it.

Look at us not doing that.

We're so good.

Mo: Give ourselves pats on
the shoulder collectively.

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?

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?

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.

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.

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.

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.

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.

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?

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

Mo: So we've gone through an, an era
over the last couple years where it's

been a heavy focus on RSCs, right?

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.

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.

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.

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.

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?

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?

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.

The bleeding edge should be there
to help push everyone forward.

It's not for every
single app that we built.

Carl: Yeah.

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.

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.

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?

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.

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?

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.

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.

It doesn't give you any real
world steps on how to apply your

theoretical knowledge of components.

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.

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,

what, when it started, as,

Mark: Her and Dan together.

Yeah.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

It's very accessible to everyone.

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.

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.

Carl: yep.

Interesting.

Yeah, I would, I would like to talk
more with you about that actually,

mark, Cool.

Mark: Moving right along.

Carl: Mo can you give us a bit of
a recap about React Native this

year as our React Native expert

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.

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.

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.

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.

We'll come back to that in
one of the next releases.

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.

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.

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.

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.

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.

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.

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.

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.

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.

It's been in the making for years.

Let's get everyone migrated away.

This was sort of the big
news for this release.

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.

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.

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.

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

Mark: We're not there yet, but
at least we're talking about it.

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.

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.

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.

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.

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.

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.

Also in October we had Expo
launching their 2025 Expo app awards.

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.

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.

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.

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.

Carl: That's a lot of releases!

Mark: I would not have known enough
to, pull in most of those items

Carl: that's a lot of releases.

I mean, we got six releases
in 12 months, like hot Damn.

That's

Mark: every two months.

That's solid.

Carl: Do you know when
it was first released?

Mo: React Native's.

First release was 2015.

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?

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.

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.

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,

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.

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.

Mo: I wouldn't say stable ish.

I'd say stable.

don't undermine the
community like that, Carl.

Carl: According to SemVer, a zero major
version you're you are allowed to release

breaking changes without a major revision.

Mo: you're telling me the
CEO was right all along.

It's not stable until it's 1.0.

Right.

Carl: I'm just saying.

technically that's what the contract says.

Mo: Technically, that is
what the contract says.

You are.

You are absolutely right.

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.

Mark: you very much, Mo.

Merry Christmas and happy
holidays to you too.

Carl: Cool.

Okay, wonderful.

Mark: Semi rapid firing our way through
the myriad of stuff we have left.

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.

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.

So I actually legitimately
take credit for that one.

Carl: I give credit for that one.

Yeah.

yeah, we, so we start with Create React
App deprecation, much better new docs.

We move into styled components getting
actually officially deprecated.

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

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.

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.

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.

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?

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.

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.

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.

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.

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.

Carl: It is absurd.

there's a visible inflection point.

I don't know.

It's, it's funny, there's
actually like two—

Mark: like January this year is
when all the AI tools took off.

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.

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.

I don't know.

This is fun.

It's just interesting to look at
some data and see some patterns.

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.

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.

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.

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.

We had the React Router remix team,
Ryan Florence and Michael Jackson

teasing us for months about what
remix V three would look like.

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.

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.

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.

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.

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.

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.

, 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.

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.

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.

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.

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.

Mark: But I absolutely respect the intent
and the effort to make that happen.

Carl: yes, it is a
massive amount of effort.

Like, it's tough.

Well, I'm excited to see how that goes.

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.

Mark: neither.

'cause I don't write, I don't
write front end apps these days.

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.

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.

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.

Mark: All right.

Well, how do you feel about just lightning
rounding everything from here on out.

Carl: Let's blast through it.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

And so then it's actually trusted and
tagged according, and flagged accordingly.

Carl: Interesting.

Oh, that's funny.

That's deep in the weeds.

Mark: Basically, I'm not doing the
literal publish step for my own machine.

It's happening from within GitHub actions.

Carl: Got it.

Cool.

Interesting.

Yeah.

Well, speaking of GitHub actions,
Jared Palmer, who is a, like

pretty, he's a huge name in React.

He did formic, he did turbo repo.

He did turbo pack.

He worked on

Mark: V0.

Carl: 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.

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.

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.

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.

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

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.

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.

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.

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.

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?"

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.

Mark: Free infrastructure
will always be abused.

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.

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.

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.

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

Mark: On a third, on a second branch.

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.

, 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.

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

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.

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.

So, basically it just sucks.

You have to go through, like,
you have to like check out the

branch in your local computer

Mark: Reset it, re push, something.

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.

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.

Well, I'm excited to
see the possibilities.

We'll see what actually happens.

Mark: And then one last ecosystemy
thing, and it's amazing that

so much happened this month.

It's almost an afterthought at this

but a, a very small company
called Anthropic bought a

little known tool called bun.

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,

Mark: might have even just
been like literally like them

chatting in person or something.

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.

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.

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.

And I think that made a lot
of sense in 2022, and it makes

a lot less sense in 2026.

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.

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.

I wanna talk about this.

SVG ClickJacking.

This is

Mark: really

Go for it!

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.

And this is like such a fun exploit.

This is taking

Mark: It was an insanely good post.

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.

Anyway, so it's, they're using
SVG filters, which let you do

some fancy visual effects on
your website in, in general,

Mark: like calculating
pixel colors, basically.

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.

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.

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.

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.

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

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.

Carl: Yeah, right.

Oh, oh my God.

That's crazy.

With

Mark: demos in the, blog post.

Carl: 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.

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.

Mark: Okay, moving right along.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

Carl: Yeah.

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.

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.

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.

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.

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.

They put out a, a post talking about
ES 26 solves JavaScript headaches

with dates, math and modules.

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.

Mark: Temporal is the big one.

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.

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.

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.

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.

Carl: Love it.

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

Mark: and blog, post in tweet form.

Carl: Yeah.

But I, I like it.

I'm gonna read some passages.

"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."

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.

Mark: The other way to look is
they basically reimplemented

a JavaScript execution stack.

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

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.

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.

Mark: Monkey, JSC.

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.

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.

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?

And with that, I think we
may finally, finally be done

Carl: we're done.

We're done.

We did it.

We did two hours of talking
about React and by God we got it.

Mark: Was, was this ever in doubt??

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.

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.

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.

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.

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.

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.

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.

Go to a meetup, say, "Hey, I
like this podcast." Awesome.

Thanks so much.

See you next month.

See you year.