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