Subscribe
Share
Share
Embed
Transcript and links 𐄁
★ Support this podcast ★
Reply on Bluesky
Reply on Bluesky
- (00:00) - This Month in React July 2026
- (01:27) - New releases
- (01:29) - Vite+ Beta
- (02:41) - TypeScript 7.0 released
- (03:56) - Open PR for “content mappers” to typecheck templates other than JSX
- (04:57) - Johnson Chu made a compatibility layer to drop-in for unsupported tools
- (05:18) - OXC type-aware linting stable
- (06:00) - NPM v12 and new security defaults
- (07:00) - Dependabot supports a configurable delay
- (07:37) - More React RSC security tweaks for 19.x
- (08:06) - Main Content
- (08:07) - React org updates
- (08:22) - “Leadership Council” and Working Group structure on the new team page
- (11:11) - Stub governance docs for the Leadership Council
- (14:37) - Rick Hanlon update on the React team using a “stage” process internally
- (15:39) - Pete Hunt and Nick Schrock join Vercel to run Frameworks/Next and Agent DX
- (17:16) - Poimandres published a charter
- (20:20) - For instance, WebGL text rendering
- (21:30) - React-alikes
- (21:40) - Octane from Dominic Gannaway
- (28:27) - Ryan Carniato: "React’s staying power is because of complacency"
- (29:12) - “Do people think FE innovation is dead?
- (30:31) - Parallel articles on Solid 2.0 with async, and Remix 3
- (32:22) - "no benchmark […] has captured the relationship between reactivity and rendering"
- (35:04) - ReactBench to measure AI code quality from Aidan Bai
- (36:37) - Alex Russell thinks everyone is screwing up state management
- (47:41) - Aurora Scharff rewrote the Suspense docs page to cover how it works
- (48:22) - And a post on RSC performance patterns
- (48:41) - TanStack removed RSCs from the website
- (51:04) - Mark is experimenting with perf improvements for RTK v3
- (57:36) - Making referential stability a type
- (59:17) - Porffor native compiler upcoming alpha
- (59:39) - Perry cross-compiles Claude Code bundle
- (01:00:17) - Marker
- (01:02:04) - Goodbye, forever, probably.
- (01:08:41) - Conferences
- (01:08:53) - Sep 11: ZurichJS, Switzerland
- (01:09:14) - Sep 25-26: React Alicante, Spain
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: Hello.
Thank you for joining us for the July
edition of This Month in React, as we
recap what's been going on with React
Native and other things across the web.
We are coming to you live
from Reactiflux, the place for
professional developers using React.
And I'm Carl.
I'm a staff product developer and
freelance community leader here at
Reactiflux, where I run community programs
like these events and build tools like
help keep the community operating.
Mark: Hi, I'm Mark.
My day job is replay.io, where
we've built time travel debugging,
are working on autonomous QA, and I
get to do all kinds of awesome time
travel-powered React analysis tools.
And outside of that, I am still
doing Redux stuff, and I'm actually
finding the energy to do a fair amount
of that right now, which is cool.
Carl: Nice.
Heck yeah.
Hell yeah for finding the energy
to invest in a project you love.
Mark: Yep.
I'm also actually back at home
after, like, two and a half months
of almost nonstop conference travel.
Carl: We were saying in prep, we
have kind of a grab bag this month.
There's not, like, one big thing
to discuss, but yeah, we're
gonna get into a couple things.
Uh, obviously there's been more
security stuff and new releases of
major projects, like TypeScript 7,
which we've discussed, like, four
times already, but y- it's here.
Yay.
We also are gonna get into some
open source governance questions.
There's been some developments
on the React Foundation.
And l- kind of out of left field at
the same time, Poimandres a cooperative
doing open source around Three.js.
It also published some governance work.
So yeah, we're gonna get into it.
But first, the first new release.
Vite+ from Voidzero is in beta now.
Mark: It's not paid anymore.
Oh, okay.
They dropped that.
I think they dropped the paid part
even before they got bought out.
They initially said it was paid.
Then they said, "No, no, we'll, we'll
make Vite+ free. We're gonna build
our own server runtime layer on top
of Cloudflare," and then Cloudflare
just bought the entire company.
So- Great … Plus itself, as far
as I know, is going to be entirely
free at this point multiply.
But it's just the Void Zero company
had been paying a bunch of people to
build out OXC, you know, that whole
layer of parser tooling, partly to use
in the Rolldown Rust-based bundler.
The latest version of Vite uses
Rolldown, but then there's all these
other Rust-based tools related to that.
And so Vite Plus is a combination
of we have pre-configured all these
different tools into one super package,
as well as added some additional
layers of functionality on top of that.
So it's essentially supposed to be
an entire JS development suite in
a box, sort of akin to what Rome
was promising a few years ago.
Carl: Cool.
Love that.
Mark: Meanwhile, as mentioned, we have
talked about this repeatedly, so I
don't have to go into a lot of details,
but TypeScript 7 is finally live.
Hooray.
This is the Go implemented native
implementation of the TypeScript
compiler that is supposed to be
up to 10X faster, so the actual…
If you install the actual TypeScript
package at latest now, it is actually
built with Go under the hood.
The biggest caveats here at the moment, as
we've again talked about, the programmatic
TypeScript API essentially does not exist
in version seven, because the API had
been partly official, partly unofficial
before that And lots of different tools
had various dependencies and needs.
A lot of them had hacked together
solutions in the past, and so the
TypeScript team said, "Okay, we
know the compiler itself's working.
We're gonna get that out the door.
We want to take our time and carefully
consider what a better and proper public
API would look like to support all the
different use cases people have come up
with, and we'll get that out the door in,
like, a version 7.1 or 7.2." so there is
some, there is an update on that front.
They've put up a PR for something
they're calling content mappers, and
the way I'm understanding this is that
for other languages like, say, View or
Angular that have templates, you want
to be able to type check the templates.
The TypeScript compiler handles
JSX, which means React kind of
got special treatment there.
But how can other languages
actually get similar behavior
for non-TypeScript syntax?
And so this content mappers proposal
from the TS team is a way that
they're hoping they can address
essentially a plug-and-play conversion
of other syntax into something
TypeScript itself can type check.
So there, there may be other API
integration things that they're looking
at as well, but this feels like it's
a, a good step in that direction.
And in the meantime, a bunch
of teams are doing things with
integrating with TS Go in hacky
ways you're not supposed to anyway.
Johnson Chu, who I think built the
Alien Signals library, and I think
also works on the Vue Volar language
extension, if I've got my connections
right, put together a package called
the TypeScript Native Bridge, which
is supposed to help polyfill some of
the, I think, the language server-type
integrations so that they're faster.
And then the OXC folks have been doing
their own hacky native TypeScript
integration to try to enable typed
lint rules within the OXC linter.
And so the typed linting support
has just gone stable as well.
So, lot of improvements around
TypeScript compiling and checking
in the entire tooling ecosystem.
Carl: Interesting.
Yeah, type-aware linting
would be a really big win.
I've wanted that a number of times,
and we've never really gotten there.
Mark: TS ESLint has them, but it requires
a lot of slower integration and running
full-blown standard TS type checking.
Carl: Cool.
Can you talk about this
install time security, Mark?
Mark: Due to the entire series of supply
chain attacks that we've seen happen over
the last year, one of the biggest issues
has been that packages are allowed to
run scripts after install by default.
And so you're just arbitrarily
executing remote code on your
machine with your privileges.
And so several other package
managers like pnpm had switched
to disallowing that by default.
And so npm 11 still allowed that,
but they started adding the options
to disable running scripts by
default and preparing things.
So npm 12 actually does flip the
switch on a lot of those options.
So npm 12 no longer runs
post-install scripts by default.
By default, it does not allow a Git
repo URL as a valid dependency, and
it has a couple other options that it
turns off by default to enable security.
I also saw that GitHub is changing
Dependabot, so it now has a cool
down by default, so it won't
install new deps until, like, two
or three days after they came out.
So we are very, very belatedly, as
an ecosystem, finally learning some
lessons we probably should have learned
many years ago, and changing some of
the default behaviors of our tools to
try to cut down on the blast radius
of some of these malware releases.
Carl: Yeah.
And we've covered some of that
in recent episodes, so I, let's
not rehash it entirely again.
Mm. Yeah, definitely some,
uh, long overdue changes here.
Mark: Yep.
Carl: As well as, I guess, in w-
security tweaks for server components
that were just released this week.
Mark: Yep.
Looks like another denial of
service attack possibility.
Carl: Okay.
Mark: So just bad, bad… So
not remote code execution, but
bad input freezes the server.
Carl: Okay.
Can't have that.
That's a denial of service vector.
Okay, well that's the, like,
brand-new releases we have.
There's some other new stuff, but a
little bit, like, less, you know…
N- we're not gonna start with it, but
we're gonna do that towards the end.
Main content.
We are gonna start with the React
org updates, and we're gonna frame
this against the backdrop of, like,
open source governance generally.
There have been some changes
announced by the, uh, you know,
React Foundation within the Discord.
There's been, you know, there's
been a, a couple of visible
changes to the website and PRs to
the actual governance repository.
Mark: I specifically had been
griping, I think in the last two
months, that I have no idea who's
even on the React team anymore.
And I don't know whether they literally
heard me or whether this was just,
you know, kind of coincidental timing.
But they did a significant update to the
existing React team page on the website.
They updated it both with, you
know, current people involved
in moving some folks to more
of, like, an emeritus status.
But the team page now actually
reflects a new team structure that is
coming out of this React foundation
itself, where there's, like, a set of
different working groups for topics
like, you know, server components
and compiler and, and other things.
But then there's, like, a leadership
council that appears to be essentially,
like, a, a representative from
each of those groups, as well
as possibly a couple others.
So I still don't, still don't have
a lot of details on the actual
responsibilities, but we're seeing some
visible evidence that they're working
on the organization process here.
Carl: Interesting.
Cool Curious, the reason I'm in the
Discord is 'cause, 'cause somebody reached
out asking if I wanted to help with
community, and so now seeing a bunch of
people listed as on the Docs and Community
Working Group and nobody reached out to
me makes me feel like I got left out.
But that's okay.
I'm an independent actor, unaffiliated.
Mark: The list of working groups is, uh,
server, DOM, fiber, docs and community,
compiler, DevX, and React Native.
Carl: Yep.
I am s- slightly surprised to see
React Native generally put into its
own single group, because they're
a- at least as large as React.
I would say technically, you know,
problem space they operate within
is larger than React itself.
So I'm slightly surprised to see
it positioned as a single working
group under the umbrella of React.
But I guess, you know, there's
other organizations that are more
meaningfully invested in React
Native, so, uh, maybe this is more
of, you know, division of labor.
This is the pipeline more
than the umbrella, per se.
Mark: It's also worth noting that
there, there's like seven or eight
people on the leadership council,
which I guess, you know, matches
roughly the number of working groups.
And then the working group members section
is at least a good 20-plus people long
for current people, and then there's a set
of advisors and a set of emeritus people.
So there, there's a good 30 to
35 names listed on this page.
Like, it's not just, you
know, two to three people.
Carl: It's quite a long list,
and it is much more specific.
I don't know.
We just complained about this, and
it's really nice to see a, like,
full refresh that looks reliable.
That's nice.
I was reading a little bit of the charter.
It is pretty interesting.
It looks like they're quite earnestly
trying to make this, like, you know, open
participation, and I've thought a lot
about governance questions and stuff like
cooperatives and, like, how do you do…
If you have multiple people with opinions
about what to do with a project, a shared
good, I don't know, it's really hard, it's
really hard to do that right in a way that
allows people to feel represented and like
they have agency in the overall system.
So I appreciate the challenge
of what they are trying to do.
It is difficult to set up a general
organization that lets many people
in many walks of life feel heard.
I like the, the way they scoped it
as, you know, "the mission and scope
of the project is to develop and
maintain React and associated open
source software. The leadership council
will be responsible for technical
oversight of the open source project."
You know, like, this is… I can
tell that from reading this, that
the way that they are discussing
responsibilities and constraints and
decision-making and work delegation,
like they are very meaningfully
trying to make this open participation
And with a high bar of quality.
Yeah.
This is, you know, primary
source kind of stuff.
This is-- The commit on this
charter.md document is two days
old, so this is, like, brand new.
No one has really been…
This is a- as yet untested.
The processes described here are
not currently fully implemented.
But yeah, what I see here
looks quite good to me.
I like it.
Mark: And to be clear, like,
the, the repo's public.
I mean, I can look at this
information right now.
I don't-- The- there hasn't been,
like, a formal team announcement of the
leadership council and the charter per
se, but clearly they're trying to put all
the pieces together to be able to say,
"This is the way we're gonna do things."
Carl: Yes.
Okay, I don't see-- I heard rumor of a,
uh, pending blog post, but I, I don't
see it yet, so… But yeah, I expect that
there should be some broader announcement
of what this is and what it means and
what their intentions are coming soon.
But what I see here looks quite good.
I like it.
It seems like a good effort.
Mark: Like I said, I, I griped a
little bit about the lack of visible
progress in the last few months, but
clearly what we're seeing here, and
even what I'd heard about the amount of
effort that was needed to just create
the foundation in the first place.
Like, there is a lot of effort going on
behind the scenes, clearly, and there's
a lot of good faith intention behind
what they're trying to accomplish.
Like, this is not just for show.
Carl: Yes.
Agreed.
Mark: One of the longstanding complaints
about- You know, the community with
React and React with the community has
been, they do most of their coding work
in public, but there's also some that
happens behind the scenes in private.
And historically, they've had the
problem that any time they push
a draft PR, people jump on it.
It's like, "Oh, React is working on this
new feature," and they start writing
blog posts and tutorials and everything.
And so that has actually made the React
team less likely to show their work in
public, because a lot of times it is an
experiment or a prototype, and there's no
guarantee that this will even ship at all.
So there's been discussion on both sides
that it would be really helpful if they
tried to follow a TC39 stages model, where
it's very clear that we are working on
concept X. It is a stage one prototype, a
stage two, like, we think this is likely.
Stage three, this is probably gonna ship.
Stage four, it's ready.
That kind of thing.
And so Rick posted a comment on Reddit
saying that they've been trained
to follow that model themselves
internally and had some success with it.
But essentially, they're trying to prove
to themselves that they can actually work
using that approach before they fully
publicly commit to doing that and making
the scale, the stages and progress public.
Carl: Yeah, and we've talked a couple
times in past episodes about the
general challenges, like the tensions
there of them earnestly wanting to
work in public and having repeatedly
tripped over the same problem every
time they've tried to of, you work in
public and then you get just a bunch
of yahoos talking over you as you're…
You know, the, the people who don't,
people who haven't seen the work that went
into the current state that is actually
now public and end up just re-litigating
all the same issues or, you know.
So there, there are a lot of very
real challenges there, and I earnestly
appreciate the continued exploration of
how to make that actually functional and
work well for as many people as possible.
Mark: One other small but related item.
You know, there are a bunch of React
folks at Vercel at this point, and
Guillermo just announced that Pete Hunt
and Nick Schrock have both joined Vercel.
Pete Hunt was one of the first advocates
for React at Facebook at the time.
He did one of the more famous talks that
helped get React off the ground in public.
He had spent the last few years,
I think, working at a company
called Dagster that just got
acquired, and so this is presumably
his chance to move on from that.
But the announcement is that
he'll be leading the frameworks
group in Next.js itself.
And then Nick Schrock was instrumental
in the development of GraphQL as a spec
at Meta, and he is gonna be working on
Agent DX or something along those lines.
So Ver- Vercel continues to scoop
up more and more of the folks
who were involved with React at
Meta at some point in the past.
Carl: Yeah, I'm curious to see about
the interplay between Agent DX and
the GraphQL, because increasingly
so, what an agent needs to do with an
arbitrary server is get the data it
wants And that's what GraphQL's good at.
Hey.
Yeah, I'm skeptical of MCP.
MCP is gonna die.
Actually, no, it's not gonna die.
It's gonna, it's gonna live forever
the way that, like, SOAP does.
Yeah.
It's gonna be an early exploration of
a, an A- API, and I think it's going
to be widely hated in five years.
Calling it now.
There's my mark on the yardstick.
Related to the org updates and open
source governance more than that
last update, though, Polymanders
has published their charter as well.
It's been around for, I would
say, at least eight years,
maybe 10 years at this point.
Oriented around Three.js and 3D
rendering on the web, I think
is a fair characterization.
Mark: A, a number of, number of folks
there have prior experience in game
development one way or the other.
Sort of a set of artists
collaborating to build related
things together kind of a vibe.
Carl: Yes.
Yes.
Right.
We all have a shared interest,
a shared passion in this.
You know, I open their website and it's
full of WebGL demos with, you know,
parallax and physics and refraction
and, you know, translucent interact…
You know, so it's, that's generally
what they're anchored around.
It's a bunch of artists doing art on
the web in different ways, playing
with visual technology on the web.
And I- when I say playing,
I don't mean to diminish.
I mean earnest play in
the sense of exploration.
Mark: It's also worth noting that
was originally developed by one of
the, one of the earlier folks in that
org, and I b- and I think Z- possibly
Zeustin and Jotai and Vultio are
still owned by that org on GitHub.
Carl: Yeah.
Zeusstand, React Three Fiber,
React Spring, Jotai, Volto, Drei.
Mark: Some very solid well-known
libraries in the React ecosystem.
Carl: Yes.
Yeah.
Tons and tons of well-known projects.
Yeah, so like, I hope that
didn't sound diminishing because
I do not mean to diminish.
These are talented, respected.
But yeah, so they, they… As a
point of comparison, these other
technical, highly technical, highly
skilled folks have also published a
charter, and I think the React one is
a little bit more clearly articulated.
I appreciate this charter.
It is, you know, it discusses the
core principles and what it means to
be a member and how decision-making
works and how they adopt projects.
But, you know, it's like the
membership is one paragraph and
says, "What are the working roles?
There's no strict definition of a
working role." So it's more vague.
There's less buttoned down there.
Which makes sense.
You know, this is an open source
collective of artists who are very
talented, and they're very talented
in more along technical things.
Like whereas people coming from Meta are
much more experienced in the corporate
aspect of precision of language and
clarity of, you know, communication
and definitions in documentation like
operating agreements and charters.
So i-it's, I'm positioning these
in reference to each other, mostly
because of the coincidence of
timing of them having both come
out at the same time, and because
I think that's a really interesting
and valuable comparison to draw.
What does it look like when a corporation
helps found a foundation versus what
does it look like when artists as part
of a collective do the same thing?
These are contrasting ideologies creating
something, and these are two examples.
I think it is fascinating to look at both.
Mark: So let's say they wanna work
on a, uh, React Three Fiber version
10 to be able to make use of WebGPU
and make it more AI agent friendly.
They'd like to work on their
own design system for common
look and feel and behavior.
And then they also want to
work on better quality text
rendering in WebGL, apparently.
Carl: Okay.
Cool.
I appreciate that.
Yeah, text rendering is really hard
because it's actually insane when you
start drilling into the details of how
glyphs are rendered on your screen.
F- 'cause like for instance, if you're on
a low DPI monitor, they will do all sorts
of crazy sub-pixel rendering in order
to make it look, you know, 20% crisper.
Which ironically actually Apple gets
flack for now because all of their
displays are high DPI, and so they
don't do those anymore, and then it's
really hard to get crisp icons on OSX.
Mark: Yeah, anytime a text rendering
article pops up on Hacker News, I
end up reading it, 'cause there,
there's some deep stuff there.
Carl: Yes.
If you see text rendering or Unicode
in a blog post title, like I highly
recommend checking it out, because you
probably take it for granted, and it's
probably like insanely complicated.
Text rendering in WebGL is likely
going to be a fascinating project
that deserves its own full initiative
from a, uh, collective of expert
engineers with visual experience.
Cool.
Okay, let's move on a little bit.
Recently, we've been covering more
and more React-alike projects.
I'm gonna coin it, I'm calling
it, these are React-alikes.
Yeah, we've got a new one,
Octane, from Dominic Ganaway.
Mark: Yeah.
Okay, so there's, there's a
whole causational chain here.
So Dominic started off by creating
a library called Inferno back in
2014 or 2015, and the idea was React
similar, but much, much faster.
Whereas Preact was, say, like React, but
only for the web and as small as possible.
So, like, there was like a Inferno-React
compat library that tried to fill in
some of the differences in behavior,
but the whole point of Inferno was let's
make something very small and very fast.
Dominic joined the actual React
team and was there for a few years.
He left Meta.
He, I believe, worked with Rich Harris in
some of the Svelte 5 stuff for a while.
And we actually covered Dominic just
in the last couple months because he
recently released a- another different
framework called Ripple, which tried
to pull together a few different ideas,
and he also released a JSX improvement
language called TSRX, and then
iterated on its design a couple times.
So he's back, and he has another new
framework called Octane, and the sales
pitch for this one is very intriguing.
It's essentially what if we took
React's syntax and pretty much almost
all the semantics, but we have a
compiler, and thanks to the compiler,
we can eliminate the virtual DOM, we
can get rid of the rules of hooks, and
actually have, like, conditional hooks,
and we don't need a dependency array.
And so there's actually a, a very strong
connecting line through all these things.
It's like what if React,
but better in certain ways.
Svelte was all compiled.
TSRX is a compiler syntax layer.
So there's a lot of different previous
threads of work that are getting
pulled together in this project.
Now, I took a look at the
commit history for this project.
It looks like he only started working
on this, like, a month or a month
or and a half ago, thereabouts.
You can pretty s- quickly see the commit
messages going from, you know, first test,
try this, oops, broke, fix, whatever, to,
like, very quickly building up the pieces
And he's officially launched it in some
sort of like, well, I don't know what
the actual version number is, but like he
feels it's ready enough for people to try.
The implementation has
obviously been AI built.
Here's where it gets interesting.
So he just joined OpenAI to
work on their own web front end.
I believe he'd been using
Claude To do the implementation.
But in some discussion on Twitter, he
said, like, "I am actually seriously
pushing Octane forward because
OpenAI heavily relies on React in
their web stack, and we need to
essentially, like, find ways to make
that faster and more optimized."
So there's both the personal history of,
"I am very familiar with React and its
ecosystem, and I'm trying to push it to
the next level, and now I have a day job
that will fund me to do that, and also g-
they get to benefit from them." One other
interesting technical point out of this.
So it's React syntax and almost React
semantics, but it's totally different
packages, which would normally
mean that there's no ecosystem out
of the box because there are no
packages that import from Octane.
There are packages that import from React.
So if you look at the Octane repo, there
is an entire subfolder where he has
programmatically built adapter layers
for commonly used React libraries to
make them work with Octane, ranging
from component libraries to, in our
case, React Redux and Redux Toolkit.
Essentially, look at the actual
source code, create a port or thin
adapter layer that imports from Octane
instead, and I assume they work?
So it's brand new and no one's using
it yet, but this looks very genuinely
fascinating on multiple levels.
Carl: The thing I'm observing on the
homepage in the announcement, you
know, code snippet, it looks extremely
familiar, except for there's no return
in this function, which is strange.
Mark: That'd be the TSRX.
Carl: Right.
Mark: In fact, n- notice if you look
carefully, there is a, there's an @ symbol
right before the opening curly brace.
That's apparently the TSRX symbol
that this just auto-returns.
Carl: See, I don't like that.
Th- th- those feel like personal
preference decisions that
don't actually really matter.
It reminds me of, like, CoffeeScript.
That was so mixed.
It was so perfect.
They had the single versus the
double arrow function, which would
change the behavior of binding this.
You know, a hyphen greater than did normal
function binding, and equals greater than
bound this automatically to the function.
And people loved that so much that we
pulled it into this language, and that's
where we got arrow functions from.
And I don't think that this at symbol
justifies it to the same degree.
Like, I don't think implicit return…
Like, JSX had an implicit return, too.
You know, it was like you
add braces or you don't.
And so adding a new symbol to
the language in order to change
the behavior of something that we
already have a, a variable on, I
think is gonna be a distraction.
I think that's a, I think that's
an API failure, I would say.
Like, the rest, plenty of these, you
know, the rest of these all seem…
It bothers me that it's so close
to being familiar, while m- making
a, a dramatic departure like that.
Implicit return is a big difference.
Mark: It's worth noting that it
does support both existing JSX
syntax and the new modified TSRX
syntax, so it is pick and choose.
Carl: Skeptical.
It's interesting.
Overall, I think this is a really good
idea and a good direction to explore.
I'm reacting strongly to that small note
because I think this is good to explore,
and that feels like a, that feels like a
unintentional self-injury that will make
it more difficult for this to succeed,
I think is why I'm calling it out.
But yeah, I think that's really cool.
Like, you know, boom, they
got a use effect in an if.
Can't do that in React.
So conveniences like that seem
really cool, and I'm excited to
see if this works, and I hope
that it doesn't introduce foot
guns that make it less successful.
Mark: Yep.
That ties into the next bit conveniently
because we organized it that way.
I think partly in, in response to
the release of Octane and some other
related discussions, Ryan Carniato had
a couple tweets that relate to this.
So, like, you know, one of Solid's
selling points has been that it
mostly looks like it re- like React.
It uses JSX syntax.
It is JavaScript inside.
Okay, the state and the effects are
different, and the getters are different.
But, like, it looks like React
much more than Angular would be.
So Ryan had a couple tweets where he was
commenting that, you know, at this point,
he feels like the… React is commonly
used largely because of complacency.
It's the modern no one got fired
for choosing IBM kind of a thing.
And then he also had a, a tweet
commenting on, like, do people just
not feel that there's going to be
any more innovation in front end?
So I mean, like, he's been talking about
a number of these points for a while,
so, like, there's not necessarily,
like, new changing details there.
That, we've talked about this before,
you know, AI is sort of encoding React as
the default, and we're also still stuck
in writing, like, 2019 era React and
not even using a lot of the newer APIs.
Carl: Yeah.
I do appreciate this chat shout-out.
"Directly contradicts the meme of
a new framework every week." Like-
Mark: Yep
…
Carl: all right.
Yeah, can't have it both ways.
We're literally, the JS ecosystem is
criticized for all things at every moment.
Mark: I mean, why not both?
We can have a new framework
and nobody uses it.
Carl: Yeah.
True.
Entirely real.
Mark: I mean, the number of times
I've seen new "React state management
library" posted on r/reactjs, man.
Carl: Yeah, you know, actually, I'm
gonna tie that back to what you just
said of not moving past 2019 era React.
People are still doing 2019 era
open source announcements of,
"Hey, I made a new library."
And like, yeah, that worked 10 years ago.
I don't think it works anymore.
But yeah.
Mark: One last little point on that note.
We've talked before about both Solid
2.0 being in beta and having some new,
uh, async features with the asynchroness
baked directly into the signals graph.
And someone put up a good, you know,
w- very well-written tutorial-like
post illustrating both just
the overall usage and talking
about some of the nuances there.
And then someone else explicitly
ported the example app into Remix
Version 3 as a intro to how you
would do things with Remix 3 as well.
Carl: Cool.
Nice.
Love that.
Anytime somebody does a direct port
of one app to a different framework,
especially in demos like this, I love it.
I listen to a lot of economics, and
there's a big thing, uh, in that
field about natural experiments.
Like, you know, y- some decision is
made, and boom, now you have a randomized
population that you can determine
the outcome of that decision on.
This feels like this, uh,
open source equivalent.
Somebody made a demo app, somebody
else ported it to an different
framework, and now we have a very pure
comparison of those two frameworks.
I have always thought it would be
incredibly valuable if we had a,
like, representative, like, "No,
this is the best possible to-do
app in nine different frameworks."
Mark: That was the whole to-do
MVC website back in the day.
Carl: But then, like, they all suck.
I feel like none of them achieved…
Individually, none of them were
actually good enough to wear that
mantle, and so it was like, wait,
actually, these are not, this is not…
Or, I don't know, maybe that's
just a reality of the fact that you
cannot actually have a single the
best anything because there are nine
different approaches to doing tables
in React, and so you cannot make a
single definitive React to-do list.
But, oh, man, I… So anyway, that's
why I love that somebody has ported one
demo app from one framework to another.
This is really good.
Mark: All right.
So there, there's a long-running
JS frameworks benchmark that's been
out there that measures things like
loading performance or swapping
items in a long list, et cetera.
That has been, like, the holy grail
that every new framework tries to
add and measure itself against.
NullVoxPopuli, who is part of the
Ember community, has put together a
sort of similar benchmark, but trying
to solely measure the reactivity
and re-rendering portion of it.
I only glanced at it.
I don't fully understand the nuances
and the differences of how, like,
what is being measured differently
than the, the JS framework benchmark.
But I've, I've watched this person long
enough to know they have a pretty good
idea what they're talking about, and so
they're trying to measure more about,
like, the, the state update sequence, I
think, than necessarily just, like, DOM
loading time or something to that effect.
Carl: Yeah.
So I mean, this table has-
Incrementing render effect.
So I guess that means the length of
time it took to render and then produce
an effect that would increment and
then thereby trigger a re-render,
an infinite loop, it sounds like.
And it's saying React took 8.7 times
longer than the baseline to just do that.
Which is,
Mark: which is Angular apparently.
Carl: Yes.
Or the baseline there was solid,
but yes, most of these Angular
is the, is the benchmark.
Okay, this is interesting.
So this, these are a lot of… This does
look like a pretty solid stress test.
You know, like 1,000 item list, one
update on 25% of items at random.
Like, that's pretty good.
You know, that reminds me of like a
stock ticker, you know, a table of stock
results with real-time prices updating.
Mark: Interesting.
I actually just dealt with that
scenario in the React Redux
prototype branch that I'm working on.
I'm going to have to go steal some
ideas from this, for this one too.
Carl: Ah, there you go.
Yeah.
I had to render sparklines
once, and do you know how many
DOM nodes are in a sparkline?
Do you know what happens if you render
one sparkline for 30 table results?
So I, yeah, the optimization that has to
go into that is kinda crazy sometimes.
But yeah, cool.
This looks like a very good benchmark.
And yeah, it is in fact saying that
Angular has the best performance
as rendered by time spent-
Mark: Doing the data update work, I think
Carl: the values here are not
super-duper helpful, I would say.
The options here are values raw,
so I don't k- I, like, I don't
know if that's raw on milliseconds.
I don't know what unit's it in, or
a score, which is also not helpful,
or multiplicative relative time.
So anyway, this is really interesting.
I think this has potential
to be very helpful.
Benchmarks are great,
and we have a new one.
Mark: And then one other benchmark, Aiden
Bai, who has been on a tear releasing
various kinds of React-related analysis
tools, right up my alley, put out a
React bench to try to measure how well
different AI models write React code.
He put together some kind of a scoring
metric for common mistakes and patterns,
and is measuring how well they actually
write good code versus bad code.
I'm assuming that a fetch in
a use effect is scored as bad.
And for the record, apparently GPT 5.6 is
leading at a 53% score on the benchmark.
Carl: Cool.
Interesting.
I love this because this is such
a, like "code crafts person"
versus "fuck it, ship it" attitude.
This is something I felt like I had
to get over in my professional career,
'cause I jumped around employers so
many times, and I was so close to the
React ecosystem, it's like, "Oh, cool.
I know all the best practices.
I know how to do it right." And then you
join a company, it's like, "Oh, you're
just putting a component in state?
Got it." Yeah, I bet the, I bet all
of these models are trained on some
pretty garbage code, because most of the
code in the world is complete garbage.
And I think that's very clearly
demonstrated by the highest
score on this being 53%.
Mark: I'm gonna have to go dig
into that benchmark to see what
they're actually scoring things on.
Carl: The time I saw a component being
put into state was during a take-home
test… No, during a whiteboard
interview for a new company, and I
terminated the interview because I was
like, "If you're doing this, then I do
not wanna work here. I am so sorry."
Mark: All right, so that,
that ties into our next item.
Alex Russell wrote a, as usual,
incendiary blog post blasting the
React ecosystem and its practices.
And as always, it's a very
well-written post, and I actually
agree with and understand a lot
of the points he's trying to make.
I disagree with the conclusions and
the way he's messaging a lot of them.
Carl: Yeah.
Mark: So his first argument is React
has built-in state management, but
the existence of dozens and dozens
of state management libraries must
mean that either React isn't a state
management system or React is an
insufficient state management system.
And I think we would all agree it's,
it is a state management system,
but it's very insufficient, the
fact that it's all tree-shaped.
So that's why we have all these
external state management libs.
He then goes on to, to blast the fact
that there's the plethora of external
state management libraries and that
they're all big and complicated and
basically just pub/sub event emitters.
But where-- He then takes it in a
very surprising direction, which is
essentially that all these different state
management libraries, quote, and I will
paraphrase, "Don't actually manage state."
They store a value at a point in time.
They are pub/sub and trigger updates,
but they don't have any sense of what
was the state over time or how do you
intelligently merge in changes over time.
And so he then points to sync engines
and CRDTs as essentially this is what I
think is the right way to manage state.
Of course, half his argument is all
these libraries are large and then
people do bad things for SSR and
hydration and send down massive JSON
blobs, and that leads to bad perf.
But he's also primarily arguing that the
entire way the React ecosystem uses the
word state management is wrong, and that
almost everybody would be better off
using some kind of a sync engine or, or
CRDT to both auto-merge changes as well
as manage the time aspect of changes.
I hear what he's saying.
I disagree on a number of levels.
When I wrote my Redux versus Context post
a few years ago, I actually explicitly
said that to me, a state management
tool is, well, essentially pub/sub.
You store a value, you have a way
to update it, you have a way to read
it, and a way to trigger updates.
All these libraries fit that category.
He's the one trying to put the extra
dimension of time on top of that.
I agree sync engines and CRDTs are
useful, and that probably a lot
more people ought to look at them.
But I feel like saying these are a blanket
solution that almost everybody should go
with if, you know, assuming you're doing
more than just server-side rendering,
feels like it's a pretty big step.
And so I had a bit of a debate with him
on Blue Sky about this, kind of trying to
probe and get him to expand on a few of
the thoughts, and he eventually did say
that like, "Yeah, I'm basically saying
that everyone needs to have a major
mental shift in how they approach thinking
about state whatsoever In applications."
Which I get what you're saying,
and number one, that's not going
to happen, and number two, I don't
agree that it needs to happen.
Carl: Yeah.
The, specifically that thought, that
expressed thought of, "the problem here is
that everyone else is thinking about this
wrong and everyone needs to learn this
new thing in order to do it correctly."
Categorically, I'm gonna say that i- if
that's your defense, it's ineffective.
Like, no one has, no idea has
ever been adopted to that extent.
Like, the best you get
is something like React.
React is one of the most widely successful
used technologies like that, and we're
discussing how badly abused it is.
So like, no, you are never going to
get everyone to do any particular
thing in a particular manner.
I also empathize.
Like, most state, quote-unquote,
in React apps is actually cache.
You know, and we've discussed how,
like, most state should just be
like React Query, because actually
you're just caching network state.
This is not your local state.
Mark: Use Nuxt, put more of it in the
URL so it, it survives a page refresh.
You know, use, use uncontrolled
form inputs, that sort of thing.
Carl: Right.
Right.
And so sure, it is probably technically,
from a technical perspective, it is
correct that we are misusing state.
State is a precisely def-
defined technical term, and
we are probably misusing it.
We are certainly misusing it.
But like, I don't know, what
are you gonna do about it?
Mark: I tried to hint at this in
the Blue Sky thread, and you didn't
really bite on my train of thought
and went in a different direction.
But like, I'm a big fan of going
back to how did we get here, what
problems were people trying to solve?
Problem A leads to problem B leads
to problem C. Each stage builds
a new tool to try to address
the previous problems we had.
We went from, you know, you can't do
JavaScript in the browser to you can
do a bunch of JavaScript in the browser
to, okay, y- we've got jQuery to make
it easier to work across browsers, but
you're just toggling a class in the DOM.
You're hoping that the DOM is
what you think it is at that point
in time, otherwise it breaks.
It's hard to scale all
these jQuery click handlers.
What if we tried using actual
variables to keep track of this data?
How do we start to write larger
scale structures and architectures?
Keeping track of all this logic's hard.
What if we just declared what
we want it to look like and let
the framework take care of it?
Okay, we're having trouble
keeping that data in sync
across large parts of our apps.
So I'm not saying that the current
React or front-end ecosystems are Great.
I'm not saying that they are, like,
you know, absolutely the best possible
theoretical way we could have landed
on doing things, but I do think it's
important to say, "This is how we
got here, and this is the real world
current state of things. What can we
practically do to improve things?"
And so I would be very happy to have
conversations with Alex about, like,
"Okay, here's how the React ecosystem
got here. I'm sure you know this already,
but, like, this is where we are. Here
are some influ- here's are some ways
we could try to nudge things and push
people towards mentally modeling."
But just starting off by saying, "React
claims to have state management and
it doesn't fit my definition, and
therefore it's wrong, and everyone
else has weighed these things on top
that aren't my definition, therefore
they're bad, and also bad at perf." I
get that he- a little bit of this is
him venting, and I think part of it
was the, "I've had these discussions,
let me write down my thoughts so I can
refer to them." okay, cool, agreed.
But it feels a little bit like shouting
into the void, and it's not going
to improve the situation at all.
Carl: Right.
Yeah.
Like, there are two little trigger
phrases here that make me go, "Er."
And one is the first sentence.
"It is by no means the gravest
linguistic crime of the React
epoch, blah, blah, blah."
But, like, okay, so, like,
literally this starts off announcing
that a gripe on semantics.
Th- this is framed as a linguistic
crime, so it's just definition
and what are we talking about.
And then at some point it's like
his stated resolution here is, "Devs
should…" And like, boom, done.
You lost me.
Devs is not precisely defined.
Who are you talking about?
Who needs to make a change?
And you just say should.
Like, devs should do something.
Like, I don't know.
Any- anytime somebody uses a general
statement about a large population
to say, "Everyone in this group
should do X," like, you're wrong.
It does not matter who you're
talking about or what your idea is.
That is never correct.
So right.
I, like, I broadly agree with
the perspective here as I-
correctly identifying a problem.
Mark: As my mom used to say to us
many times growing up, "You stated
the problem, now state the solution."
Carl: Right.
It's a problem.
The solution is hard.
Like, there are lots of very smart people
working very earnestly on this problem.
You know, we as an industry are
exploring the cutting edge of UI and
what does it mean to interact, you know,
human computer interaction used to be
considered a field of academic research.
And, like, all of us are HCI experts
with no credentials and no…
Like, you know, there's no scientific
rigor behind the experiments we do.
Our company, our companies just say,
like, "Oh, I think this should be-" A
dropdown instead of a type ahead select.
And like, you know, okay, why?
Oh, well, you know, that's
what the design, that's what
the design spec calls for.
Okay, well, why?
Well, that's what the designer wrote down.
Well, okay, does that, how
would people interact with that?
This is a human computer interaction
question, and there is a body of research.
We are earnestly exploring all of this
without the support of traditional, like,
in years past, in decades past, people
doing this type of exploration of a, a
problem space might have the support of
things like academic journals with peer
review, and then ultimately, if it's
published in this journal, then you can
trust that it went through this review
process and, you know, that by being
present in its current form, it represents
a consensus from this perspective.
And like, we don't have that.
We have blog posts.
Like, you know, we have
vibes of popularity.
So like, we're exploring a really
challenging problem space without
very much ability to capture the
results of those explorations, and
that's a very hard space to be in.
But that to say, I think there's a lot
of really interesting stuff happening
with sync engines, Electric SQL.
I've, I remember hearing about
a long time ago, the… Oh, God,
I can't remember some of them.
There were a lot of really good
sync engineed and local first-
Mark: Electric, Zero, Replicache, maybe
that, maybe those are the same company.
Howard Sync is out there, I think.
Carl: Yeah.
Thank you for filling in the gap.
I have lots of the ideology and
less of the, uh, proper nouns.
But so yeah, yes, correct.
This is a problem.
People do misuse date, quote, unquote.
But yeah, the way you change that is
by effectively broadcasting a message
that allows people to observe that their
previous practices were incorrect and
guides them into more correct practices.
Mark: Update the docs, add a
linter, build it in by default.
Carl: Right.
None of those include an angry blog post.
I relate to that as someone who wishes to
write angry blog posts, but I don't think
it's an effective solution to the problem
Mark: Aurora Scharf, who has been doing
a lot of fantastic conference talks
and blogs on using Next.js and using
Suspense in the last couple years,
joined Vercel and i- in a dev role,
role, and has been, I guess, part
of or working with the React team.
I think she's actually
listed on the team page.
And so she actually just did a
significant update to the Suspense
docs page to add a lot of details on
what are all the cases that actually
trigger a Suspense boundary, as well
as some of the, the other use cases.
So again, great to see a lot of the,
the usage and technical details being
fleshed out in the official docs.
Always something I'm asking for.
Yay.
Uh, and then she also wrote on her
own blog a, a post on some various
Suspense-related usage patterns
that she's been playing around with.
Cool.
On the flip side, the TanStack folks have
added initial server component support
in its own form to TanStack Start.
We've talked about that
in previous months.
And I believe they had been using that in
the actual TanStack.com website, primarily
to move heavy markdown rendering to the
server so you weren't shipping the, the
markdown rendering logic to the client
and having to wait for that to happen.
And apparently they've removed that.
They put up a post saying they actually
pulled out the server component usage.
It worked, but it, they weren't getting
a lot of benefit out of it, and it was
actually hurting perf in some ways.
And instead, they have
restructured things.
They've actually shipped a couple of very
tiny libraries to do markdown parsing,
and then separately, syntax highlighting.
And so essentially going back to a
somewhat more SPA-ish approach, but
minimizing the amount of work done so
they still get fairly fast loading times.
Carl: Nice.
Let me tell you, doing syntax highlighting
on a documentation site is fucking crazy.
I underweighted that as a problem
circa 2018, and it almost killed
the entire project, because we had
wanted a single API reference page
constructed from dozens of markdown
documents, so we could maintain it as
individual docs, but have it presented
in a single, large, searchable page.
And holy shit, we were shipping 12
megabytes of HTML across the wire
because of syntax highlighting.
We took syntax highlighting out, and it
dropped to, like, you know, 600 kilobytes.
Which is still insane, and, like, part
of the reason it almost killed the
project, because we just were trying
to put too much docs on one webpage.
But- Yeah, man, like when you start
highlighting individual, every individual
character and wrapping it in glyphs, in a
span which has a class name, and, uh, so
it's, it is insane how much markup bloat
gets added just by syntax highlighting.
So moving that from rendered on
the server, shipped to the client,
into data is passed from server
to client and then rendered on, on
the client makes total sense to me.
But that's why this is the cutting edge
of UI, 'cause like that sounds so obvious.
Of course you just want a rendered page
to come directly from the browser and
oops, that rendered page is 20 times
larger than it could be if you just
sent the raw data needed to render it.
So that's why it's so impossible to
answer the question abstractly of
whether or not server components are
right for you, 'cause I don't know.
Do you know?
Anyway, that's a fun project.
This is a really good case study.
I love it.
Mark, tell us, I'm giving
you an opening to talk about
your performance prototyping.
Mark: So I'm pretty sure I alluded
to this two months ago, and then
I linked the draft PR last month.
But for the last few years, I've been
kicking around the idea that surely there
is some way that I can magically use some
combination of signals and proxies inside
of React Redux to speed up performance
updates in large scale applications.
So cases where you have thousands of
connected components, and right now
we have to run all end subscribers
and selectors on every dispatched
action just for each selector to
grab its state and diff the result
and see if it needs to update.
That's fine when you've got
500 or 1,000 components.
When you've got 5,000, 10,000, whatever,
that's just the overhead of calling
those subscribers is expensive.
So I played around with a couple
proof of concepts in previous years.
They were like, you know, like
one-off, I'm gonna hack on something,
and didn't get any further.
So I finally came back to that , and I
did a whole bunch of research on other
signals libraries, proxy-using libraries.
What do they do?
How do they work?
What are they good at?
Where do they break?
All very AI powered.
And I have a working branch that adds a
useSignalSelector hook to React Redux that
is using the Alien Signals library inside.
And essentially what it does is it wraps
your selector so that the data is in a
proxy, tracks what fields got accessed,
and then essentially precomputes, "Hey,
this was the state that got updated.
Do we think that selector actually
needs to run? Nah, skip it." With
the idea being that in most cases,
only a relative handful of selectors
actually need to rerun most of the time.
So if we can just pre-skip most of them,
that ends up being a performance win.
So I have a draft PR.
It works, and it appears to
be a significant performance
win almost across the board.
In terms of the number of updates,
in terms of the total amount of
scripting time that executes.
It's a little bit slower in the mounting
phase because it takes more work to set
up the signal and the tracking time.
There's definitely going to
be some bigger bundle size.
I don't know how big, like 5 to 10K maybe.
And there's also a few weird
cases, like doing certain identity
comparisons won't work because you're
comparing the proxy reference and
not something inside the proxy.
But it feels good enough, and I've
got solid enough test coverage that
I actually feel very good that, like,
this is a, this is the direction that
I would probably end up shipping.
There's a lot of work to figure out
around real-world testing and, you know,
like all, all the, all the non-fun stuff
around actually shipping real software.
Uh, but the idea is it would
be a separate set of exports.
You would intentionally
choose to use this.
So like most apps would still have
useSelector by default, but if you have
a large-scale app and performance is a
problem, then-- And you, you could choose
to import this and make slightly different
trade-offs in performance and bundle size.
So I feel pretty good about that,
and I'm, I'm still finding time to
try to push that direction forward.
I'm also thinking about what a notional
Redux Toolkit 3.0 would look like.
Uh, a couple years ago when I
shipped 2.0, and I said at the time
that I was deferring touching RTK
Query at all because there's some
unknown number of breaking changes
we would probably wanna make.
I don't even know what those are.
We'll just kick that can down the road.
Well, we've successfully kicked
the can down the road almost
three years at this point.
Uh, the ecosystem is actually
going ESM-only at this point.
So presumably, if and when we
do a 3.0, it would be ESM-only.
Um, but I've had a bunch of things on
my mind in terms of rough spots in our
API and the way the internals have just
evolved over time, but in a kind of
haphazard way because people keep asking
us to add options or capabilities, and
we just added them without ever really,
like, doing a coherent design upfront.
And so there's, there's a bunch
of pain points I've known about.
There's a bunch of things
I would like to improve.
But they were all, you
know, if, maybe, someday.
And so actually just in the last 48
hours, I did a whole bunch of AI-powered
research tasks saying, "Here's all
the things I would like to have, the
properties and qualities I'd like to
have in a 3.0, um, some new options
I'd like to add that we can't do right
now because they break with TypeScript.
Could we possibly come up with some kind
of an API design that looks basically the
same But is just different enough to clean
things up and unlock the constraints.
And, uh, as of last night,
I've got a local prototype that
Claude claims actually, like,
does most of what I wanna do.
So, like, noth- nothing's happening
anytime soon over here, but, like, I
actually have had the time and effort
to do this because the AI can do the
dirty work, and frankly, I didn't
have the time or effort or mental
capacity to do that work myself.
And so being able to tell it, "Here's
what I want. Can you just, like, run for
a while and, and come back to me and tell
me if this works?" has actually made this
possible, which is actually pretty cool.
So nothing's, like, nothing's gonna
ship anytime soon, but I actually
like the direction this is going.
Carl: That's super fun.
I love having problems within a box
that is clearly defined enough to
where AI can do it in that kind of way.
A lot of the problems I've been exploring
are primarily in my head, and so
getting them out of my head and into
a state that AI can check against is
its own task, and so it's a problem.
Mark: Part of me feels a little
bad that some of my contribution
here was just saying the equivalent
of, "I don't like that answer.
Try again.
Think harder." But also, like, I had
to come up with, "Here's the list of
constraints that I want to satisfy and
the problems I want to solve, and here's
the list of the prior research we did.
Now go think hard on these things." Like,
I am actually driving the work here.
Carl: Right.
Having that body of knowledge and
research is critical, and is real
work, and should not be discounted.
Cool.
Into a couple of final
details before we wrap up.
This is a fun aside.
Making referential stability a type.
So React relies pretty heavily
on referential stability, which
is triple equals equality.
If you have two objects or arrays
that are equal to each other, it
is literally the same reference.
It is the same pointer.
It's in this, the same part of memory.
And someone made a type that
represents that, which is crazy.
I don't understand how they did that.
I saw our resident TypeScript wizard
here, who is the person-- I think
they're the only person who's answered
any types question I've had in the
last, like, decade, possibly literally.
My favorite types wizard said,
"Oh, cool. I tried to do this
and gave up." Which I just love.
Like, yeah, this is a hard problem.
It's really cool.
It would be really nice to have.
Somebody seems to have put together
a real effort at it, and I love that.
It's cool.
Mark: Yeah, what they bork
on both Preact and GraphQL.
They're one of the Preact maintainers.
Carl: Oh, cool.
I love that.
Wow.
Real-- I don't know.
They got real chops.
Yeah, core team of Preact,
Urql, and- Gql.tada.
So yeah, okay, they've got some real
experience with wrangling complex data.
That's awesome.
Mark: There's been an interesting
set of different projects around
trying to compile TypeScript
code to true native code.
One that's been out there for a
while is called AssemblyScript, and
it's essentially a, a restricted
subset of TypeScript, not full-blown
true JavaScript semantics.
But there's three different projects
I've seen recently that are attempts
to compile just straight-up TypeScript
code to native code in some form.
One's called Porffor, which is
a… It's a single-person project.
He's been posting about this for a
while and doing a lot of performance
optimizations on the output lately, and
even making the compiler self-hosting.
So he announced that Pro4 is about ready
to hit alpha stage in the next few weeks.
So that, that's a pretty massive
technical achievement there.
A second one called Perry that I,
I don't know who's working on this,
but I saw it pop up pretty recently.
So they're also trying to compile
TypeScript to native code, and they
recently put up an article about
taking the entire, like, 13-megabyte
Claude code bundle that ships on
disk and compiling that to native.
And part of it's the compilation process,
and part of it is all the semantics
and non-JS bits that it expects, like
relying on the, the message channel,
message port interface to, to send
messages back and forth over a microtask.
And then Vercel just announced something
called ScriptC, and this is apparently
in their Vercel Labs area, which is where
they put all their vibe-coded projects.
And, uh, boy was this one vibe-coded,
I think someone on Hacker News
points out that the first commit
is 800,000 lines a week ago.
Yeah, so who knows what the
actual quality is there, but
they're playing around with that.
So Bunch of different people trying
to solve the same problem of, it's
both the publishing aspect and the
runtime execution speed aspect.
Carl: Cool.
Interesting.
Well, I would love it if we had some
more native compiled… what attention
we experience, because native
compiling is also the thing getting
suppressed by NPM for security reasons.
So yeah, what, what attention the
ecosystem is under right now of moving
away from compiled dependencies,
but also being very hungry for the
kind of performance improvements
that native code is capable of.
Mark: I mean, I think in general,
packages that have a native dependency
used to rely on a postinstall script
to check your local environment and
then go manually download the binary.
And at this point, most of them, like ES
Build, have switched over to we're just
gonna publish a se- a separate package
for each possible native architecture.
And then the package managers have
gotten smart enough to say, "Oh, well,
each of those packages lists a certain
native environment that it needs. Let's
only actually install the one that
matches your current environment."
Carl: Fair.
Interesting.
Complex, nuanced, subtle.
Mark: Programming.
Carl: Programming.
Facts.
Cool, okay.
Our last link for you today is,
I don't know, it's kind of sad.
Goodbye Forever, Probably.
Mark: It's very personal.
Carl: Very personal.
This is by Salma Alam-Naylor,
who goes by White Panther online.
They were a very talented developer
relations person for quite a while.
I feel like they sprung up out
of nowhere, or at least I didn't
see them before they were huge.
And I always thought they were
very, very, just very skilled at it.
I thought they did a really good
job of being technically at the
cutting edge, while being, like,
personable and entertaining.
And, like, that's really hard.
All three of those is really hard to do.
But, so anyway, she put out this blog
post called Goodbye Forever, Probably:
Why I'm Leaving Developer Relations and
Why I'm Not Telling You What's Next.
And oh man, I gotta say, a
lot of this resonated with me.
I've actually never had a job
described as developer relations.
I'm just a developer who blogged
and has engaged with the community,
which then later turned into
the job of developer relations.
This whole thing I relate to so much.
Like, the number of times I've sat and
seriously contemplated if I wanted to
keep doing what I was doing is, like-
At least five, possibly more than 10.
I think about it often.
And I've always stuck it out.
I don't know, here I am.
Probably because nobody's paying
me and because I have full agency
over everything I do, which has
its own different trade-offs.
And yeah, I don't know.
This is just a really good articulation
of how hard it is to be publicly
visible in tech and to get paid for it.
And I think that if you are someone
who consumes tech content, this is
a really good read to see what it's
like on the other side of the page.
Mark: Yeah.
So, um, makes a, an, a
bunch of different points.
A lot of it is around dev rel as
a job role, that it's, it is by
its nature really hard to measure.
You know, how are you… Like, what
metrics are you being measured on?
How are you trying to
contribute to the company?
How do you even know if
you're having success?
What is your role?
Are you going to conferences,
writing blog posts, writing
documentation, that sort of thing.
But specifically she also talks about
being heavily overworked at multiple
companies, and that contributing things.
She'd spent a lot, a
lot of time streaming.
That was a really big part of
her online persona, both in
and out of the day job role.
So that, that sucks up a
lot of time and effort.
But then also talking about
AI killing teaching content.
When she linked this post publicly on
Blue Sky, there was a massive number
of responses, and I know somewhere
down in the replies, Josh Comeau
said that he's looking at taking a
break from building courses as well.
So when you put in massive amounts of time
and effort to carefully craft a teaching
course, and then either y- you don't
get much payoff because people aren't
buying it or the content essentially
just ends up getting swiped Yeah.
Like, why put in the time?
Carl: Yep.
I was thinking about Josh and this as
well, 'cause Salma says here, "I've too
often overworked myself in desperate
attempt to justify my existence. This
has more than once caused me to suffer
from health problems, including joint
and nerve pain. At its worst, I couldn't
even use my hands due to the pain."
That happened to Josh.
Like, both Josh and Salma had to learn
to code with their voice because of
hand injuries as a result of overwork.
So, like, these are two extremely
successful people who have, as in
pursuing their success, ground their
bodies into a state of non-function.
So, like, that's the industry we're in.
I don't know.
This is what working in tech does.
This is what succeeding in tech does.
It's hard.
One of the decisions I made in
producing this podcast was I
am not targeting entry level.
This is not educational.
This is not catch up, this
is stay on the cutting edge.
And part of that was because
of looking at the economics and
realizing that, like, you know what?
If you're targeting entry
level people, the market you're
chasing doesn't have the income.
They don't have money.
They're trying to get into tech.
Part of the reason I have never targeted
entry level humans in tech, trying to
get into tech, is because I felt the
economics of it was pretty fucked up.
It was, you're taking money from
people who aspire to get into
tech to get the high salaries,
and that's playing off people's
desperation to succeed and do well.
And, like, ultimately, like sure, while
the money was flowing, while it was
easy to get into tech, while you could
self-teach and then get a full-time
job that pays you six figures, like
fuck yeah, that was a great deal.
That was great.
That was phenomenal.
It was a good part of the world to be in.
And now you can't.
And so I think we're gonna watch
a lot of educators' careers dry up
because for all the good they did
for the people, the market they're
serving to doesn't have the money.
They're trying to get the money.
I think we're gonna see
more of this, unfortunately.
It's gonna get blamed on AI, and,
but there is a portion of that.
People don't seek-- People are
self-educating less often and
relying on AI to learn more of those
nuts and bolts details for them.
That's true.
But I do think there's another
real problem of incentives.
You know, this reminds me too of
GitHub just announced, their sponsors
program, the GitHub sponsors program,
you know, they waved the banner.
They, you know, did the proud
marketing announcement that $100
million has flowed through the
program since its inception in 2018.
So since 2018, 2019 I think it
was actually, 'cause the number
in my head is seven years.
But so over the past seven years of
GitHub having a sponsorship program, $100
million has flowed through it in total.
Mark: 14 million a year.
Carl: Yeah.
I did 30 seconds of back of the napkin
research and math, and the number
I came up with for venture capital
dollars that flowed just in SF over
the same time period is 200 billion.
So while content creators are chasing
their piece of $100 million, the
businesses are chasing 200 times that.
Thousands of times the
sums of money involved.
So like, I- it's, for all the commentary
about, you know, who's doing what in
education and content and making money,
like at the end of the day, like there's a
stereotype of a certain political subgroup
that all just passes around the same $20.
You get it, and you give it to someone
else, and they give it to someone
else, and they give it to someone else.
And like that's how I see
programs like GitHub sponsors.
It's not a sustainable ecosystem
'cause you're all just passing the
same $20 around at the end of the day.
The money's coming from somewhere else.
So that's my… Sorry, that's my
political rant at the end of this.
It's rough.
It's rough out there.
Mark, did you add these conferences?
Should we read them?
Mark: Yeah, I put them in here,
uh, because I will actually be
speaking at both of them, and
they're, they're also coming up.
So listing the two conferences off the
top of my head that I know I'll be at.
ZurichJS in Zurich,
Switzerland on September 11th.
The primary organizer, Faris
Aziz, great person, first year
putting on the conference.
I have a sense of how much time
and effort he has put into trying
to organize this conference.
Fantastic person, ton of effort, and
I'm really looking forward to that one.
Great list of speakers as well.
And then, uh, React Alicante is in
Spain September 25th and 26th, o-
out on the Mediterranean coastline.
This will be my third
straight year speaking there.
Again, wonderful conference, great
community vibe, highly recommended.
So if any of you happen to be in
Europe or can make your way over to
Europe, definitely check those out.
Carl: Heck yeah.
Well, that's everything we got for you.
Thank you for listening.
We'll be back here on the live stage on
the last Wednesday of August, or back in
your podcast feed just as soon as we can.
Man, maybe, hopefully I'll get it
in by the end of the month in July.
I've been bad at that lately.
Sorry everybody.
Yeah, thank you so much for
listening, especially to those of
you who made it all the way through
the end to hear this gratitude.
Mark: We started the day by saying
we've got a grab bag of stuff.
Yeah, we never run out
of stuff to talk about.
We cut out 15 items.
Carl: Yeah, we did cut out legitimately 15
items and still went 30 minutes over time.
Yep.
That's us.
Thanks so much.
If there's feedback you wanna send,
if there's tips you wanna give, please
email them to hello@reactiflux.com.
I read every email that comes through.
It's a low number.
It's very easy.
If this is a show that you get
value from and wanna support, the
best way to do so is by submitting
a review wherever you listen and by
sending this episode to your friends.
Thanks so much.
See you next month.