Subscribe
Share
Share
Embed
Transcript and URLs
★ Support this podcast ★
Reply on Bluesky
★ Support this podcast ★
Reply on Bluesky
- (00:00) - This Month in React: June News Roundup
- (00:11) - Intros
- (02:24) - [React Router 8](https://remix.run/blog/react-router-v8)
- (05:29) - [Babel 8](https://babeljs.io/blog/2026/06/16/8.0.0/)
- (07:05) - [Astro 7](https://astro.build/blog/astro-7/)
- (09:03) - [TS 7.0 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-rc/)
- (09:31) - ESM only, no programmatic API right now
- (10:31) - [Nub JS](https://nubjs.com/), from Zod creator
- (14:03) - [Legend List 3.0 with DOM support](https://x.com/jmeistrich/status/2059922504320225316)
- (14:34) - [TSRX revamped the syntax](https://tsrx.dev/blog/rethinking-tsrx)
- (16:18) - React Core news
- (16:22) - [React Compiler in Rust is rolling out](https://bsky.app/profile/sebastienlorber.com/post/3moibsmtqjk2x)
- (16:47) - [PR was merged after testing at Meta and improved](https://github.com/react/react/pull/36173#issuecomment-4608356402)
- (17:24) - [Oxlint, SWC, RSPack, Next all integrating](https://bsky.app/profile/sebastienlorber.com/post/3moibsmtqjk2x%20)
- (17:40) - [Rolldown tried integrating directly but removed due to binary size increase](https://x.com/evanyou/status/2069593612153987373)
- (18:08) - [Bun tried optimizing the Rust Compiler code](https://gist.github.com/Jarred-Sumner/84df369c35216f40d61d1ea9f95771c2)
- (18:47) - Other core improvements
- (19:07) - [Fragment Refs have been documented](https://react.dev/reference/react/Fragment#fragmentinstance) in canary
- (21:31) - React DevTools MCP tools, including [component tree](https://github.com/react/react/pull/36597) and [perf analysis](https://github.com/react/react/pull/36598) APIs
- (22:18) - React Foundation progress
- (22:29) - There’s a(n early) [react.foundation](https://react.foundation/) website, advertising funding for maintainers and community groups
- (25:30) - They’re gonna have a booth at [Chain React at the end of July](https://chainreactconf.com/)
- (26:01) - [Why is Meta destroying its engineering organization?](https://newsletter.pragmaticengineer.com/p/why-is-meta-destroying-its-engineering)
- (32:36) - [AI demands more engineering discipline. Not less](https://charitydotwtf.substack.com/p/ai-demands-more-engineering-discipline)
- (40:41) - Christoph Nakazawa posted his [“Modern Engineering Values” and how he uses AI](https://cpojer.net/posts/modern-engineering-values)
- (42:31) - [Cloudflare bought VoidZero](https://voidzero.dev/posts/voidzero-cloudflare)
- (43:34) - NPM / security updates
- (43:38) - [Github Actions allows enforcing pinned action SHAs](https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/)
- (44:11) - [GitHub Actions Has a Package Manager, and It Might Be the Worst](https://nesbitt.io/2025/12/06/github-actions-package-manager.html)
- (45:17) - [NPM 12 will disable install scripts and Git deps by default](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/)
- (46:15) - Code optimization still matters!
- (46:43) - [TanStack Table cut memory in v9 by 90% on large lists by optimizing JS objects](https://tanstack.com/blog/tanstack-table-v9-memory-performance) and [optimized TS perf](https://tanstack.com/blog/tanstack-table-v9-typescript-performance)
- (47:15) - [Pierre Diffs was significantly optimized](https://pierre.computer/writing/on-rendering-diffs) - has to handle virtualization, syntax highlighting, source loading
- (48:27) - [CompileCat is a new optimizing compiler to improve JS execution after bundling](https://github.com/isaac-mason/compilecat), similar to Closure Compiler. ([the RSPack team says they’re working on something similar](https://x.com/jiahan_c/status/2065630866668453898) )
- (51:12) - [Mark’s React-Redux /+ signals draft perf PR](https://github.com/reduxjs/react-redux/pull/2318) and [updated React-Redux benchmarks repo](https://github.com/reduxjs/react-redux-benchmarks)
- (52:41) - [Aurora Scharff’s preferred RSC component architecture](https://aurorascharff.no/posts/component-architecture-for-react-server-components/)
- (53:24) - [Lovable projects now use TanStack Start by default](https://lovable.dev/blog/building-apps-using-tanstack-start)
Creators and Guests
Host
What is This Month in React?
How busy professionals stay on top of the React ecosystem. We give you a 1 hour recap of the latest news and nuance in React's development and ecosystem, upcoming conferences, and open source releases. New episodes the first week of every month, with live recordings on the last Wednesday of every month in the Reactiflux stage.
Hosted Mark Erikson (Redux maintainer), Carl Vitullo (startup veteran), and Mo Khazali (head of mobile at Theodo). See something for us? Post to #tech-reads-and-news
Carl: All right.
Hello.
Thank you for joining us for the
June edition of This Month in React.
We're coming to you live from
Reactiflux, the best place for
professional developers using React.
I am Carl.
I'm a staff product developer and
freelance community leader here at,
Reactiflux, where I do things like
build Euno, a moderation bot that
helps us keep the community operating.
Mark: I'm Mark Erikson.
My day job is at Replay.io where
we use time travel debugging to
build things like automated QA
tools and awesome React analysis.
And outside of that, I run
around at conferences, give
talks, and work on Redux.
Carl: Heck yeah.
The big news that we wanna discuss
this month, is around some changes
that shipped for the React compiler.
it's in Rust now.
There you go.
It's the news.
You don't have to listen.
Yeah.
we're gonna talk about Meta and we're
gonna talk about its engineering
culture, b- framed around a blog
post from Gergely Orosz, who is
wonderful and a great writer.
yeah.
Talk a little bit more about AI,
'cause of course we are, and some
broad best practices and stuff.
Carl (editing): And I'm trying
something we haven't done before today.
I'm gonna self-sponsor this
'cause we don't have anyone
else paying our bills right now.
Uh, we are sponsored by Euno,
a moderator support tool for
Discord, offering one-click setup
for spam defense, moderation audit
logs, and decision-making tools.
That's euno.
reactiflux.com, uh, Euno is
named after the goddess of good
order and lawful governance.
Uh, it helps moderators make decisions
about bans together while automatically
filtering out compromised account spam.
A single setup/command gets you
anonymous user reports, shared
moderation history and resolution
voting, a private ticketing channel,
and anti-spam based on message velocity.
With a 90-day trial, you can get a
feel for it before deciding if $100
per year is worth the time you'll save
banning spammers and deleting garbage.
If you have a Discord server,
give it a shot and let me know.
That's euno.reactiflux.com,
E-U-N-O.react iflux.com.
Mark: Yep.
congrats to you, Carl.
Thank you for all the work you've put in
on this, and I can, vouch that this has
been very thoroughly tested on our end.
Carl (editing): We're also
sponsored by me, Carl.
Uh, these episodes cost me about 300
bucks out of pocket each episode,
uh, for editing and supporting tools.
If you'd like to learn more about
anything Mark and I discuss,
let's talk about consulting or a
contract software engineering gig.
You probably know where to find me, but
Discord or email is the most reliable.
I'm at vcarl, that's Victor Charlie
Alpha Romeo Lima, @reactiflux.com.
Let me know
Carl: But yeah, first the new releases.
First up, React Router v8 shipped.
We got that now.
yeah.
This… they talk a lot about the
early days of React Router, and it…
they're, like, proactively trying to
manage the pain that people experience
because, I… React Router got a
reputation for shipping a lot of
breaking changes with every new release.
I guess specifically they got a reputation
of flip-flopping back and forth between
two different paradigms, like every
other release, and it just frustrated a
lot of people with, "Why do we have to
refactor again?" So it's funny how much
of this blog post is dedicated to saying,
"We're not doing that anymore, we swear.
Please don't hate us."
But yeah, generally it looks
like this is essentially a no-op
versus the latest version of v7.
if you are already using the
latest version of seven with
no, deprecated features, it…
This should be a drop-in replacement.
yeah, I think this, As far as I know,
the mo- most of what th- this is bringing
out is, emphasis on the framework mode.
Mark: I know that they've done a
lot of work on trying to use feature
flags to make new features available,
essentially following the, majors
don't introduce new stuff, they
just remove old stuff kind of a
Carl: pattern.
And see, so the feature flags are
the way that they implemented the
better, major version releases.
So th- now by the time, by the end of
the previous major version release, they
will have introduced new feature flags
for everything that they are about to
release in the next breaking change.
which is, it's really smart.
I actually really admire
that method of changing.
managing feature flags, I have
experienced, adds a lot of
complexity to day-to-day development.
and I have a ton of respect for
them for landing on this process for
releasing new changes, new features,
new abilities to their widely used
library, and here they are still, eight
years later after they started using
this, still putting it to practice.
Mark: Couple interesting notes
from the support matrix here.
Node 22, okay, that's fine.
they now require at least React 19.2
Carl: as
Mark: a minimum version, so that…
I, don't know if version 7 expected
19.0 or 18, I would have to check.
But just noting that React Router now
requires the latest and greatest React 19.
And also the package is shipping
as ESM only, we are very clearly
now on the trend of lots of tools
and libraries going ESM only.
there was the early wave of tools
that went ESM only and everyone else
complained because it didn't work right.
And now with, some of the
improvements to Node itself,
we're seeing a lot of packages
say now is the time to go ESM only
Carl: Yeah, we've got another
release that went ESM only next.
I wanna flag, I just found… I was
clicking through the blog post and they
have a link to their governance document,
which explains their new feature process.
and actually this whole document is
very well thought out and I would
highly recommend that you familiarize
yourself with this governance document,
'cause, it's just a bunch of really
high quality engineering practices.
Definitely check it out.
Mark: So on the, ESM note, Babel
8 just shipped, and the, big
highlights there, the Babel packages
themselves are also now ESM only.
TypeScript types are built in, and
the default compilation settings
for building your projects no
longer target ES5 or CommonJS.
So essentially they're saying we've,
rather than necessarily being about
backwards compatibility by default and
always trying to cross-compile your code
to, support, IE 11 or whatever, now we're
targeting the modern JavaScript ecosystem.
Which is also pretty much what,
TypeScript 7 is doing as well.
Carl: I am extremely
here for that transition.
I wish that it had
happened several years ago.
Babel as a compatibility layer I think is
really good and really great, but we've
been on evergreen browsers for most of my
career at this point, and I, yeah, just,
the long tail of what it means to support
ESM 5 and Require is just, it's really…
That tail's really long at this point.
It's very far away.
I don't know.
I, think the, trade-offs
are not quite there.
Yeah.
Yeah, Babel 7.
I don't know.
I've, Are people still manually
installing and managing Ba-
Babel versions themselves?
This feels like something I haven't
wrangled with personally in a long time.
It's all downstream of the
rest of the tools I use
Mark: Yeah, I'm disconnected enough
from day-to-day app development that I
don't have an answer to that question.
Carl: fair.
Ha Okay.
Anyway, moving on.
We've got Astro v7,
major release of Astro.
Astro's a project that I have always meant
to explore more deeply than I really have.
I have used it for a, trivial
project here or there.
If you're building a static portfolio
site, brochure, marketing, whatever
you wanna call it, it's really good.
it hits a good balance between engineering
ability, it gives you escape hatches
to manually control stuff, while
still being largely content oriented.
So it's very good if what you're managing
is what's on the page rather than, like,
how it behaves or what data's available.
so it, not as great for a full app.
there are certain types of
apps that work great in that
environment, but an application less
Mark: Like my mental model of Astro
is it essentially replaces Gatsby
Carl: Yes
Mark: in terms of, we, we pull in
data sources, we build sites that
are static by default, but can
have lots of dynamic content with
your rendering framework of choice
Carl: Would agree with that,
with all the same caveats of
a lot of apps need something a
lot more complicated than that.
But if you're building co- a content
site, it's a really great tool for that.
Yeah.
Looks like mostly they're touting, s-
build improvements, upgraded internal
dependencies, V8, new roll down bundler.
Mark: Faster markdown parsing.
Carl: Yeah.
Advanced routing to give you
a single entry point with full
control over the request pipeline.
They can detect coding agents
automatically that looks like
a local development feature.
It's, you can run the dev server in
the background and output structured
JSON for machine-readable feedback.
That's really smart, actually.
I love that.
there's a ton of cases where,
just like in testing and such,
raw human readable HTML and CSS,
it… that's just a lot of content.
It's a lot of bytes.
It's a lot of tokens.
so giving machine-readable outputs at
the framework level is really helpful.
I like that a lot.
That seems like a really smart
feature, and I think we're gonna
start seeing that for more.
Mark: And I mentioned this a minute
ago and we've mentioned it in previous
episodes, but TypeScript version
7 is now at release candidate.
think the biggest change here from
a user point of view is that p- the
previous releases had shipped as a
separate native preview package and
now it's the actual TypeScript package
itself, the RC tag has all new binary
and faster compilation stuff in there.
One other thing to note is that the,
7.0 release, number one, it builds
off 6.0 where they change the default
settings to favor modern compatibility
instead of backwards compatibility.
but then also 7.0 will not
ship with a programmatic API.
So tools that depend on the c- on
the TypeScript compiler package to
programmatically drive compilation,
parse files, do that sort of thing,
will not work out of the box with 7.
The idea was get the full working compiler
in people's hands now and they're still
trying to nail down the details of what
the programmatic API will be like, and
they're hoping to have that out in a 7.1
Carl: Cool.
Nice.
Yeah, and we discussed that at more
length last month, so I don't know
that I wanna rehash all of that again.
Difference between beta and
RC is just not that big.
Mark: Okay, the, the next
one's very interesting.
Colin, the creator of Zod, just
announced something called nub.
Those of you with keen eyes will notice
that this is bun backwards, in the
same way that Deno is Node rearranged.
clearly there's only so many
letters we can use in naming
JavaScript runtimes at this point.
The s- the sales pitch for this,
Node was run JavaScript on the
file system outside the browser.
Deno was, "Oops, we made a bunch
of mistakes designing Node.
Let's completely redesign the security
and the process architecture and bake
a bunch more stuff in." Bun was, "Let's
build Node compatibility on a different
JavaScript engine, and also add every
other built-in programming method and
API we can think of while we're at
it so it does everything at once."
Nub, on the other hand, is, "Let's start
with actual Node, let's override a bunch
of its configuration options, and let's
build in a more modern environment, things
like better TypeScript stripping and
better, package JSON handling and a bunch
of other pieces into Node directly so it
feels like Node much better rather than
one of the, one of the other options."
I, like this idea.
we've been using things like
ts-node and TSX and all these
other type-stripping approaches.
Node has a type-stripping option built in.
This apparently goes up to the
level of being able to output the
non-strippable pieces of TS syntax,
so like e- enums and things like that.
But then it bakes in a whole
bunch of other features as well.
I like this idea.
I, it, makes a lot of sense to me
Carl: I'd agree.
It's interesting.
I was always skeptical about
Bun because of what you said, it
starts from a brand-new runtime,
and runtimes are difficult.
It's hard.
It's… Getting it right is tricky.
clearly it's worked well enough
for many people, but I've
struggled with it a little bit.
Sure, There's plenty of room
for opportunity in the tools
surrounding Node.js as well.
But I'm skeptical of this package manager.
It says a pnpm-compatible manager built
in, and it, reads whatever lock file you
already have, writes to the same format.
I don't know.
I'm skeptical of that.
look, we made a magic package
manager that is cross-compatible
with every existing package manager.
sure, I'm sure you did.
Can't wait to find out
what bugs you missed.
Mark: I saw a tweet from Colin where
he said that this was all implemented
with AI, not surprisingly given today's
no but it, but there was a lot of
very careful planning and, defining
the feature set and working out the
requirements and then, using the
agents to actually do the work on it
Carl: And, like we s- we were talking
about last month, if you've got an
existing set of tests to make sure that
your code works against which all of these
open source package managers are going
to, then it's definitely a lot easier
to create a functioning replacement.
yeah, I don't know.
It's interesting.
Curious, we'll, we'll
see how it shakes out.
We'll see if it works.
see how it does for people
Mark: Yep.
Another release announcement.
Legend List 3.0 came out, and this
is originally, I think the original
version of this was React Native only.
Jay Misiorek's also the creator of
the Legend State Signals library.
but apparently he's figured out how to
port the underlying list virtualization
logic over to React DOM as well, and
says that it's one of the fastest,
if n- if not the actual fastest
virtualized list implementation out there
.
And then, other follow-up note, I think
it was last month we had mentioned
something called TSRX, where Dominic
Ganaway and the Ripple project had said,
"We're, annoyed at the JSX specification
being stuck for, the last 10 to 12 years.
We have come up with what we think
is a better syntax, that, adds
more flexibility." And, after
they announced it, they got a
bunch of feedback on, people not
liking some of what they designed.
And so th- they did a couple different
blog posts about how they've stepped
back and rethought what the syntax is.
Things like, the original TSRX wanted you
to put quotes around every bit of text
that you had in there, whereas JSX just
is angle bracket, words, angle bracket.
And so they've, gone back to
that as a syntax for text.
So to be honest, I don't have a
good mental picture of what the
actual differences are between this
and JSX at this point, 'cause I,
haven't gone through it in detail.
But they, looks like they do have some
control flow syntax embedded as well.
so they're somewhere in between
their original p- proposal
and standard JSX at this point
Carl: Neat.
It's a big swing.
I said last month that I think it's
interesting that now in the AI era
you can just update documentation and
the tool knows how to use it, which
was not the case for previously.
So that might make it easier for tools
like this to succeed, because you
can just drop in a different markdown
document and the tools will know how
to write the new code, so to an extent.
It's not perfect.
Let's get into the main content
with some React core updates first?
Mark: All right, so the biggest thing
this month is that the React compiler
port into Rust has officially been
merged, and there's been a whole flurry
of activity of different build tools
now trying to actually integrate this.
so the React teams had said, "We have been
trying out the port at Meta. It appears to
emit identical results with the TypeScript
implementation of the compiler." they did
a bunch of work to optimize it and handle
some more cases, and the PR itself got
merged, about a week-ish ago, I think.
So now that it's at least more or
less available, then the question
is, how do you actually use it?
I don't know if you can actually
just install the Rust version
of the compiler right now.
I'd have to double-check that.
But n- since we have a whole bunch
of build tools, and most of today's
build tools are now written in
Rust, a lot of different teams have
been exploring how do we actually
integrate this into the build tools.
So Oxlint, SWC, RSpack, Next, and
Bun have all been trying to figure
out how do we integrate with this,
make it a, an option or built-in
or something along those lines.
One interesting note is that Rolldown
tried to actually add this into their
system, so there would just be a built-in
turn on the React compiler option.
And what they saw was that it increased
the binary size from, 28 megs to 33
megs, and they decided that was too
much extra size to force everybody
to download, actually reverted
it, and they're exploring further
options on how they can integrate it.
On the other hand, Bun taking the Rust
code and tried to both integrate it and
also see can we improve the Rust code
itself to make the compiler run faster.
I think a couple of the other teams
have also been seeing, now that the
Rust code for the compiler exists,
can we also make it faster as well?
So there's clearly still a lot of
development opportunities for different
teams to explore in terms of how is
it integrated into the build step,
how fast does it run, but we now
at least have the merged PR as a
baseline for all that different work
Couple other things I noticed.
one is that the React team has
been working on something called
Fragment Refs for a while.
We, might have mentioned this
once or twice in the past.
Carl: Yeah, I think
not a long time though.
It's b- it's been a minute
Mark: it's been a while.
The PRs were sitting out there
or getting quietly iterated on.
So the idea for a Fragment Ref is that
a React fragment by design does not
have any single DOM node associated
with it, because it's meant to be like
a virtual container for many children.
That's why we wrap them in a
fragment in the first place.
but what happens if you want to
do something like listen to a
DOM event for any of the children
directly underneath the fragment,
or perform some other DOM operation?
So Fragment Refs are a, I think, now in
Canary feature where you can put a ref
prop onto a fragment and you get back
something that looks like a DOM node in
terms of the methods you can call, add
event listener and that sort of thing.
and under the hood, React just does
the work to pass the references on
to all of its children automatically.
So it looks to your code like you're
dealing with an actual DOM node, and
under the hood, React takes care of,
oh, there's 15 children directly under
this fragment, let me just collect
the interactions with all of them.
So, that is apparently now in Canary,
and they've actually updated the
documentation page on fragments to
say that you can use refs on them
Carl: Nice.
Cool.
the value here I think is really
specific, and, it might, be unintuitive.
it… let's say you wanted all of
those DOM methods you just talked
about, you wanted to be able to
measure the size of this block of
nodes or add an event or whatever.
Another way you could do
that is to wrap it in a div.
If you have a div, cool,
great, free DOM node.
You can do all those things.
but that doesn't work in certain layouts.
if you wanted to have a grid where
all of them share a single, drag end
event, you can't just wrap that in a
div because that breaks the grid layout.
So this is a situation for, flex or
grid, where there's an implied mandatory
hierarchy of the DOM nodes itself, and
you are rendering those s- containers,
those children, s- let's say from a map.
You're mapping over data, then this
is super helpful for adding a whole
bunch of different types of behaviors,
which is why it's worth the effort.
Mark: And then one other thing that I
have a vested interest in, the re- there's
been a series of PRs posted to improve
the React Dev Tools by adding MCP tools
so that agents can query and inspect it.
some form of imperative API so that
you can programmatically ask, what
is the component tree, and even turn
performance profiling on and off.
and then some, some additional
wrappers to expose that data.
I've spent a bunch of time doing
React performance analysis work.
I am doing some of that
at my day job right now.
so I'm, I am also keeping a very
close eye on this because it's very
heav- heavily related to my interests.
Carl: Yes, it is.
Yeah, and we've got…
we mentioned briefly the React Foundation
last month, and most of what we said
was that we haven't been able to
see very much of what's happening.
We can see things.
Visible change is happening.
The React repos have moved, there's
also a new website being developed.
I've seen some chatter about that.
Mark: Like the, foundation page
exists, but the, uh the current
form of the page is very vibe coded.
And so, a- they're, like what's there
is accurate, but not well designed.
Carl: Yeah, it is
definitely vibe coded vibes.
but yeah, so that, that,
should change soon.
Mark: The, couple of the interesting
bits for me, if you look at the,
React Foundation website right now,
there's a strong emphasis on helping
support the community financially.
Some of that is they're apparently
intending to sell swag, shirts, and
whatever, they intend money fairly
to maintainers of some of the most
common React ecosystem libraries.
They also talk- they've also talked
both in the past and I think on the
website about helping financially
support different, communities,
meetups, conferences as well.
And then I think they are taking over
running the official React Conf as well
Carl: Yeah, I know that they've
actually been having some
struggles getting meetups.
they wanna support local React-based
meetups, people aren't doing
local React-based meetups anymore.
It's all AI stuff or whatever.
it's… I think the… I, think
my intuition here a little bit is
that some of their mental model for
how the React community exists is
still, maybe not fully reacted to
the shifts over the last two years.
I love the idea of collecting nonprofit
donations and then distributing
them out to library maintainers.
I think that is super, super good.
And doing it with a, proper
foundation with, governance and a
board of directors is super good.
I've ac- I actually thought quite a bit
about trying to do a business adjacent
to this, just, hey, we got a community.
What if we did, a bunch of little
events and had a membership
subscription or whatever, and then
funneled 80% of that money to the
people who make the community exist.
and I, ended up not just
'cause it's it was hard.
It's a lot of work.
It's a ton.
Access also helps.
starting from I am the manager of
the React core team is a very strong
position to create a foundation.
Mark: the flip side of all this is
that as I discussed last month, I
have no idea what's going on with
the development of React itself.
the- there's PRs around the
compiler and the dev tools.
I really haven't seen much activity on
the core library in the last few months.
Joe Savona c- and put up a post
confirming that he is no longer
on the React team at Meta.
He's now working on something AI related.
and then that kind of ties into what
we'll talk about in a minute with
what is going on at Meta anyway.
So here feels like the development
process on React itself is rather
fragmented and confused right now
Carl: Which is unfortunate.
But if you wanna talk to the core team
or, some members of the foundation,
or generally people close to the
development of React, they will have
a booth at Chain React, July 30th,
which it's a React Native conference
specifically, And it is, where is it?
And it is in Portland.
So yeah, if you're, around the
Pacific Northwest or willing to
travel, so yeah, check it out.
Okay, moving on a little bit.
jumping off your tangent you
just teed me up for, thank you.
Why is Meta destroying its
engineering organization?
this is a newsletter post put
out by Gergely Orosz, who's
very influential, I would say.
He puts out a, pragmatic
engineering newsletter.
It's very good.
I read it occasionally.
I read posts from him.
Mark: well written and sourced
Carl: Very well-sourced, very timely.
He does a good job of being timely.
so y- this is a, this, is again,
a well-written, well-researched,
well-presented post, talking about the
engineering values of Meta historically.
it brings in the, original
Facebook little red book, which
is a little, culture document
describing the values of the company.
Mark: move fast and break things,
but also like a, lot of stuff
about how we want to think about
building stuff for the customer
Carl: Yeah.
okay, so Move Fast and
Break Things is notorious.
here are eight, no seven other
values from the same book.
Done is better than perfect,
fail harder,
what would you do if you weren't afraid,
every day feels like a week,
the Wright brothers did
not have pilot licenses,
the foolish wait and
fortune favors the bold.
And I don't know, a lot of those
are values I can, agree with.
Mark: It's better to get something
done and see what happens than to
waste all of our time discussing
if we should try doing something
Carl: Yeah.
Yeah.
So I don't know, it's, it's a good doc.
This is good speaking about the
engineering cultural history and some
of the actual timelines of improvements
and, releases that they made.
and it's, it lists a number of problems.
th- they started tracking
engineers' keystrokes with no
way to opt out on work laptops.
it says "30 to 50% of engineers and core
teams have been forcefully reassigned to
data labeling." You think you're gonna
be a core AI engineer and oops, you're
just n- t- you're a competent, skilled
professional tagging data the same as
a legion of other competent, skilled
professionals training your replacement.
I have a, friend of mine who was
recently laid off from Meta who has
been involved in, basically, just
trying to resist this type of pressure.
like for being forcefully reassigned
to a team that you are not
interested in being on, that sucks.
and it's part of your contract.
It's ultimately, at the end of the day,
you're in a hierarchical corporate system.
They have hired you to perform work at
their leisure, at their desire, and it is
entirely within their legal contractual
right to say, "You work on this now."
and that doesn't, What if it,
wasn't their contractual right?
What if they did have to actually
negotiate with you and put you
somewhere that was mutually compatible?
So I don't know.
That's, that's the pushback that they
have been trying to support and organize.
But, meta is maybe not doing so great.
I guess, one, one concrete engineering
point that this, draws attention to was
the r- disappointing AI model development.
Like losing momentum effectively.
Like Llama 1, 2, 3 were all very
cutting-edge and competitive, and
Llama 4 released over a year ago now,
which I guess was the last release.
I don't know of another release from them.
so yeah, I don't… as a
symptom of declining engineering
culture, their frontier AI
model is no longer competitive.
Mark: Yeah.
So some of the points it makes is
that they, they, used to have v-
pretty good engineering culture
based on we're, trying to build the
right things the right way at scale.
The question of, whether the apps
that they're building are useful
for society is a different question,
but at least they were mostly
trying to build them the right way.
And now it seems like in the last year or
two they have shifted to a focus on AI.
They've had a bunch of layoffs.
Engineers have been forcefully reassigned,
and the, I know the performance review
topic c- has come up repeatedly when I've
talked to even, React core team members.
They, they want to spend their time doing
things that will benefit the greater
React community, but they have to, in
order to get good performance reviews,
they have to show, like, how is this
actually benefiting Meta the company.
And so whether that's something like,
"We're gonna build this new React feature
because it makes Ads Manager faster,"
or, just, interactions in some way.
So that I know has been a struggle
just for the React team, and it's
clearly a major problem for everyone
else at the company at this point.
How justify my existence?
Carl: there's a book that I love
called Moral Mazes that speaks a
lot about this type of problem.
we, we're talking about
engineering culture.
That's… Culture is the downstream
result of a vast group of people
interacting with each other.
The culture is the emergent
property of how those individuals
interact with each other.
And Moral Mazes is a really wonderful
sociological study of the firm,
the c- the American corporation.
And so it ends up speaking a lot about
subjects like performance reviews.
And here in this blog post, the Pragmatic
Engineer Newsletter, it says, "The biggest
problem, people stop caring about real
work and focus on performative work."
and like what you just said about how
they can't do what's best for the overall
growth of the library because that's not
the criteria upon which they're judged.
They are judged on their impact
within the company, and specifically
the impact on the company as judged
by their immediate supervisor
with, with the supervisor chain.
So it, ultimately you're… The,
incentives flow down in that kind of way.
So it's actually…
there's, a deep fundamental misalignment
between open source and, the American
corporation, I'm not gonna go into
capitalism a w- But, that's very true.
Open source is a c- is a public good.
It's a, it's, it's a public square.
It's a shared resource that
they're, people don't pay for.
and those types of resources
they're the economic concept
of the tragedy of the commons.
It's a well-known principle that people
don't just casually take care of stuff.
If it's a public common, it's going to
get more extraction than it is investment.
So it's… I don't know.
It's, it, there, the, th- that's
a fundamental tension, and I feel
like any time we're talking about
companies under-investing in,
open source, that's kinda why.
It's because they can't.
They're not allowed to.
If you're a big publicly traded company
that has gone to IPO and has shareholders,
you have a fiduciary duty to those
shareholders, and fiduciary duty does not
include volunteer effort to public goods.
So it's, that's, there you go.
That's the tension.
Anyway, let's move on
Great post from Charity Majors who,
somebody who I've … They, are such
a well-spoken, phenomenal writer
speaking about engineering culture.
And I, especially they talk about
opera- or, yeah, I was gonna say
operationalizing, production environments.
they run a company that makes
its money on observability,
Mark: Honeycomb
Carl: Honeycomb.
great company, great mission,
great blogger, great writer.
so i- she's put out a post, AI Demands
More Engineering Discipline, Not Less.
Charity says in her post, "What happened
in 2025 was this, the economics of
code production were turned upside
down. Instead of being very hard,
time-consuming, and expensive to
generate code, it became effectively
free and instant. Lines of code went from
being treasured, reused, cared for and
carefully curated to being disposable
and regenerable practically overnight."
And something I've said on
this podcast before is that,
code's kind of a liability.
over time code is not
an asset, it is a drain.
It is something to be maintained.
It is a cost center.
so I agree with that.
I think that read is correct.
The, economics of code production
were turned upside down.
it's m- because code is not an asset,
because code is a liability, the ability
to discard it and replace it with
something new that is, has differ- has
a different risk profile is massive.
Mark: It's, ironic because, as developers
we have historically resisted, taking
the time to write documentation or
writing tests or actually planning out
our work, and suddenly it turns out that
in order to get good results from AI,
we actually need to do all of the above.
Carl: Yeah, and it's like I have always
known what the right choice to make was.
it's y- several years ago when
I was working as a tech lead,
it's okay, we have this feature.
I know that it is deficient
in these , these areas.
no, we don't have end-to-end tests.
no, we don't have functional
integration tests for all corner cases.
Because we don't have an existing
end-to-end harness, because we don't have
a framework for mocking network responses
for requests initiated from components
deep in the tree, deep in the hierarchy.
there, it's, it… Engineering
excellence is a momentum-based metric.
You cannot skip ahead
You can't write end-to-end tests if you
haven't built a reliable framework upon
which to run end-to-end test suites.
and so it's hard to do.
It's hard to keep that momentum up
over a long enough time span to where
you start observing the benefits,
and so most companies didn't.
the number of times where I would get
feedback on something, and it's like, why
don't we have this already?" It's, 'cause
that would've taken two weeks, and I can
do it now, but I didn't have two weeks."
and I gotta say, I'm finding it much
easier to find those two weeks with AI.
AI is an amnesiac, so it needs
to start from scratch every time.
if you're working on a new feature or
just built something brand new, I just
ask Claude, "Hey, familiarize yourself
with this code base, how much of that
did you get from docs versus the code?"
And it does a little analysis, and
it comes back and says, "Oh, the
documentation is out of date in
these locations, and these concepts
should be pulled in." "Great.
Can you do that work for
me?" It's like, "Oh, yeah.
Cool, cool.
And so then instead of, what, six hours
of, reading code and putting together
my own notes and understanding what
documentation is currently available
and synthesizing it to get, a fact-based
update and then writing brand-new prose
to fill in those docs, I, I, I can do that
in 10 minutes in a background process.
Mark: Yeah, I, love generating
architecture exploration
e- explanation type docs.
I've, found that extremely useful.
In fact, that was my gateway
that eventually led to me
using aI to write code.
It does feel like I'm leaving
some understanding on the table,
that my understanding is can be
very much more surface level.
some of it is, there's ar- areas
of our code base and our projects
I just haven't looked at, and
operating off of a vague mental model.
I, skimmed through a handful
of architecture docs.
that's certainly not, that's certainly not
enough to actually understand what's going
Yeah place.
It's, easier entry, but
maybe not as much depth
Carl: That's very true.
I assuage my own guilt in that, the like,
"Oh no, I, know that I'm only seeing
30% of this." ' Cause for one, every
code base is too large for your brain.
you are never going to fully
understand all of it at the same time.
And any time that I did fully
understand something, the, amount
of time it took to get to that
understanding, and then the only time
I ever did that was to change it,
Mark: Mm.
Carl: So then as soon as I'm
done with that, as soon as I have
gotten my understanding up to
100%, cool, great, I'm changing it.
That's now out of date.
That knowledge is now useless.
Mark: I'm, sure I've mentioned
this in previous episodes.
I am a huge fan of the concept
that programming is building a
working mental model of the system.
it's a, it's about theory building.
So you understand what we are trying
to build as a domain, as a project.
You understand the current system, the
architecture, the quirks, the concepts,
so that for any task you work on, whether
it's a feature, a bug, whatever, you are
starting from my current understanding.
You break down the new problem
based on your understanding.
You come up with a plan, you implement
it, you spend six hours trying to make
it work, and by the time you're done,
you not only have working code, you have
updated your mental model on the system.
So I would say it's not that
you've made your previous knowledge
useless, but we are continually
modifying that understanding
Carl: Yes, sure.
I agree with that.
I agree with that, but I also discount it
a little bit more than I think you are.
Like, I'd agree that, developing
an, accurate mental model is core.
You need to do that as writing,
as part of writing code.
I, at least, am satisfied at
the level that I am able to
develop a mental model w- via AI.
I guess th- this is, a feedback cycle.
You have to develop your mental
model, check it against what the AI
is telling you, and then make sure
it's what you intended, and then
make sure that what you intended is
compatible with a functioning projec-
will it achieve what you meant it to?
And those are all really hard, oh,
another thing I wanna say your mental
model, are, the building blocks
that you have available to develop
your mental model, are those complex
enough to, capture what you're making?
That's something I run into fairly often.
It's like the system architecture, the
system design inter- interview questions.
Like, how would you build
Twitter to be re- resilient?
Those are hard problems.
That's re- you know, de- developing
a system that can manage hundreds
of millions of requests is, yeah,
it's really tough, and AI is really
helpful for me for exploring that.
it ends up being… Okay, oh, wait, here
let me try and frame this in a sentence.
It used to be critically essential to
develop an accurate mental model through
the process of reading and writing code
yourself, and now it's much more important
to be able to ask the correct question
at the correct time of the code base.
Because now you can… The, frontier
models are smart enough and the tools
are capable enough, they can pretty
meaningfully answer any question that
you have about a fixed set of code.
If you, bound it to like, "Here's the
code, here's your world, tell me about
it. Answer this question for me," it can.
And so now it's up to you to know what
the right questions are to ask given
the present state of the existing code
Mark: Yeah.
So let's tie that then into
the next link in the list.
so Krzysztof Nakazawa is a long
time figure in the React ecosystem.
He's worked on Jest and graphQL
and a whole bunch of other tools.
more recently, he shipped a data
fetching library called Fate.
he's built a game with
JavaScript called Athena Crisis.
He got hired by Void Zero, which
we'll talk about in a second.
so like re- like really smart,
capable long-term engineer, and he is
now fully doing everything with AI.
Carl: Yep.
Mark: He put up a post on modern
engineering values where he talk about
how he uses AI effectively, but also
then what are the principles that he's
using in trying to build projects.
And he talks about, ownership and
taste and strict guardrails and
fast feedbacks loops, which is
what we were hitting on a minute
Carl: Yep.
Mark: Being able, to know what
is the right context that I feed
into the agents so that they are
able to come up with the answers.
maybe actually, owning some
more your own code instead of
depending on third-party libraries.
Thinking differently about how you
build prototypes and ship things.
so very relevant to like we're,
doing the same work, but maybe at
a higher level, and you do have
to know where you're trying to go
Carl: Yes.
Yeah, agree.
Yeah, I like this, bit from Christoph's
post, "I've found that coding agents now
write code that is as good or better than
what I could write," which I would agree.
I find that true as well.
"And they do it in minutes instead of
weeks. Since coding is no longer the
bottleneck, I get a lot of work done that
otherwise wouldn't have happened at all."
100% agree with that.
That is… I have started and
finished so many more projects than
I would have before because I, can
do it in a day instead of in a week.
it's a 7X speed multiplier for me.
So it's good.
Mark: In industry news, Void Zero, the
company behind VitePlus and a couple other
pieces, has been bought by Cloudflare,
this continues the trend of a bunch of
open source build tool developers try
to get funding, try to make a company,
and then they probably get swallowed up
by someone bigger because there is no
money in running open source build tools.
Bun and a whole bunch of
others all getting bought out.
nobody is making money off
of open source build tools.
There is no build m- there is no financial
model, hosting, or anything else.
So we'll see how it plays out.
to be clear, this is about
the team and the VitePlus and
Void tool sets and frameworks.
This does not affect Vite, the open source
bundler, at all, other than these are
some of the same people working on it.
but it continues the pattern, and I don't
see that pattern changing anytime soon
Carl: We got some more
security updates from NPM.
Great.
GitHub Actions now supports blocking
and pinning actions to a specific SHA.
So that's, that's really good.
If you… So this is helpful
for avoiding vulnerable actions.
if you're aware that some specific
release of an action was compromised,
you can now block that one specifically.
Or say, "We know this one is
good. Only use this version." wow.
Ability to select precisely
what code you're running.
This feels like table stakes to me.
It's shocking that we're
only just getting it
Mark: there's, a guy named Andrew
Nesbitt, I think we may have linked
one or two of his articles previously,
but he has become an expert on package
managers and packaging systems,
and I think he wrote an, a couple
articles talking about, yep, GitHub
Actions is totally a package manager.
It doesn't look like one,
but it is, and it's bad
Carl: Yes.
Yeah, people shit on NPM for a
lot of reasons, but you know what?
The w- most most of the ecosystem problems
in JavaScript around dependencies are
because NPM is one of the only functional
package managers in programming.
Cargo or NuGet or, like,
all of the other…
Every other language has a
shitty dependency manager.
It does not support what I would call
core features of a dependency manager.
For instance, pinning versions.
Just, it's shocking to me how
ineffective we are at sharing code
in the vast majority of programming.
anyway, yeah.
So great.
So many things are terrible dependency
managers, and GitHub Actions is now a
slightly less terrible pa- package manager
GitHub also put out some
breaking changes for npm 12.
They are not going to run install
scripts and Git dependencies by default.
that is… This is literally
something I've seen discussed as a
security vulnerability for 10 years.
So it finally got exploited enough
times that they're like, "Nope, okay,
we gotta get rid of it." great, cool.
They're getting rid of the thing that
has been discussed as something that
should be gotten rid of for a long time
specifically it's, NPM will no
longer run pre-install, install, or
post-install scripts from dependencies
unless you allow list them.
So no builds basically
Mark: what I think pnpm als- already does
Carl: Plenty of package managers already
do that because running untrustworthy
code from a network is really dangerous.
Don't do it.
This is what I mean, like, I just
said, NPM is one of the most advanced
package managers in all of programming,
and it still gets basic shit wrong.
Stop it.
Security models.
Mark: All right, last
major item for the day.
topic, a related topic,
but, bit of a grab bag.
There's a whole bunch of good articles
about code optimization that came out
in the last few weeks, and I've spent a
lot of time doing performance profiling.
I have literally given a talk this year
on how to do performance profiling.
So we had several articles on, and
from people who did performance
optimization work on tools and libraries.
First off, there's a couple articles
from the TanStack Table folks where
they talked about how they were able
to save a bunch of memory within
TanStack Table by switching out the
JavaScript prototypes that were being
used, as well as how they optimized,
the TypeScript compilation performance.
Now, yes, TypeScript's version
seven's gonna make all our TypeScript
faster, whatever, but it's still
good to actually try to improve
the, type checking time if possible.
next, there's something called the
Pierre Computer Company, which is
making essentially like a, GitHub for,
as a service kind of a, set of tools.
And they've put out a couple JavaScript
libraries, one for rendering tree views
in the UI, but they also put out one
that is a diffs rendering library.
And so they've put up a post on
how they heavily optimized all the
list virtualization and the syntax
highlighting and all the other
complexities of trying to render
diffs efficiently in the browser.
And I've seen several other applications
pop up which use that library in the UI.
part of me make, wonders if GitHub
perhaps consider using that library
in their UI given the, how slow their
React based, PR view is at this point
Carl (editing): oh, shoot.
We had an audio problem.
For some reason, we lost about
the last 10 minutes of my audio.
Mark's came through just fine.
Uh, and luckily he did most of the
talking in the last little bit here.
Uh, but unfortunately we lost
about four to five minutes of me
responding to things that Mark said.
Uh, oops, sorry.
Mark: A couple more of these.
So someone recently started a
site called Performance.dev.
Their first article previously was on
how the linear UI is fast using sync
engines, and they just put up another
post on how a tool called Conductor
implemented a bunch of optimizations,
handling some of the UI layer interaction
with Tari, list virtualization,
and a bunch of other pieces.
so those are, apps and
libraries making things faster.
I saw a couple, winks
on something different.
So we all use minifiers
in our bundling process.
It's, part of all modern
build tool chains.
minifiers do things like they don't just
rename variables from my variable to A.
They, they strip white space.
They turn true and false into bang
zero and bang one be- because it
takes up fewer characters, et cetera.
But they also do things like
stripping out dead code.
So if a library has only r- has a,
an if statement that says, "Only
run this in development," it will
convert that to if false, and then it
will say, "Oh, that code can't run.
Just delete that code from the
bundle and optimize the output."
And so every time you run a build,
a minifier is optimizing the output.
And the major mini- the major
minifiers, optimizers have been things
like Terser and, ESBuild has had one
built in, Rolldown has one built in.
there's be- there's one that's
been around for a very long time
called the Google Closure Compiler.
this dates back to when Google first built
a lot of their early web spa type tooling.
2008, 2009, somewhere in that timeframe.
it's, extremely powerful and has a
lot of very advanced optimizations
that other minifiers still don't have,
but it's also big and complicated and
maybe a little bit on the slow side.
interestingly, the React team still uses
the Closure Compiler to build the React
library so that the production version of
React is as fast as it can possibly be.
So I saw two different announcements
of teams that are attempting to write
their own advanced optimizer tools.
one person built something called
CompileCat, and then the other one's
a mention of an internal tool that's
not released yet, but the, RSPACK
team at ByteDance said they're
also working on a similar tool.
So presumably doing things like
actually looking at not just the
JavaScript, but the TypeScript types
in order to be able to, be smarter and
produce better output code as well.
And then I guess we'll wrap up this
section with three things for me.
so I, think I briefly mentioned
last month that I was working
on a proof of concept to try to
optimize React-Redux's subscription
notifications for our large applications.
so I have a draft PR, and I've
put that up, and the early numbers
look promising, like 20% to 30%
faster depending on the situation.
as part of that, I also updated my
React-Redux benchmarks repo so that I've
got better metrics that I'm capturing
and, a better, more realistic set of
example scenarios to be measuring against.
And then one of the conference talks that
I've been doing this year is literally on
the basics of performance optimization.
there's a set of general scientific
principles to apply, descriptions of
actual tools that you would use to measure
JavaScript performance and fi- try to
figure out which lines of code are slow,
and I talk about some of the examples
I did while working on Immer last fall
I think this is all very important
even in the age of an AI because
AI tends to write the obvious code.
It doesn't necessarily
write the fast code.
And we collectively were already
very bad at asking, "Is this
code fast?" in the first place
when we were the ones writing it.
And now that n- we're not the ones
writing it, it's even easier to
never ask the question, "Is it fast?"
Carl (editing): Yep.
So right here is where we
lost about four minutes.
Uh, unfortunately, I, I
definitely cannot reproduce what
I said, which is a big bummer.
I think it was probably really
smart and really clever and really
wrapped up the whole thing of
what we talked about all episode.
But unfortunately, it's
gone into the ether.
I tried re-extracting the audio
as recorded from the original
source, and it was just blank.
We're just completely missing 10 minutes.
sorry.
All I really know is that I was
introducing Aurora Sharf's blog
post titled "Component Architecture
for React Server Components" as her
preferred RSC component architecture.
And I know that because Mark said after
Mark AI filler: yeah.
And, Aurora really is the expert
on this kind of stuff right now
And then one, one other interesting
data point to wrap up, announced
that all of their Vibe-coded app
projects are now going to be built
with TanStack Start by default.
I don't remember whether they
were just using plain Vite React
router or something previously.
but this feels it, it's a
very interesting data point.
A sign of the maturity of TanStack Start,
and that they're, and they're happy to
actually adopt this as the default setup
for all their projects going forward.
Carl (editing): And that is
all we've got for you today.
I am re-recording this afterwards
just like all the other things
I said in the last 10 minutes.
So I'm not gonna do the usual
full sign-off 'cause this is
totally fake and I'm just sitting
at my desk talking to myself.
Sorry for taking a few extra
days to get the podcast out.
I am just tired and it's summer
Thanks so much for listening
all the way to the end even.
talk to you next month