Subscribe
Share
Share
Embed
Transcript and URLs 𐄁
★ Support this podcast ★
Reply on Bluesky
Reply on Bluesky
- (00:00) - tmir-2026-08
- (00:55) - New releases
- (01:02) - Waku 1.0 (RC)
- (03:01) - Preact 11.0.0-rc.1
- (03:56) - Mobx 7.0
- (04:32) - Next 16.3
- (06:55) - React Native 0.87
- (07:47) - TanStack Table 9
- (09:25) - TC39 “Composites” proposal (~ replaces Records and Tuples)
- (10:44) - Solid 2.0 RC
- (13:39) - Bun 1.4
- (17:18) - Github stacked PRs in public preview
- (21:38) - Main Content
- (21:42) - React core-ish
- (21:49) - New ReactDOM `use(browser())` API
- (22:47) - React Foundation website updated
- (23:18) - Big Next.js AMA in /r/reactjs
- (23:49) - React Compiler support in OXC
- (25:21) - Biome and Bun 1.4 have initial support as well
- (25:45) - The asteroid currently hitting frontend web development
- (32:36) - Scott Tolinski’s “True Cost of AI Coding” survey and video
- (37:51) - Josh Goldberg stepped back from OSS work
- (40:53) - Software Stewardship Lab announced (Daniel Roe et al)
- (42:11) - Humanity in OSS
- (46:47) - Cursor switched from Solid to React
- (47:46) - Lovable moved off Next to TanStack Start
- (49:00) - Ryan Carniato’s async Solid articles
- (49:33) - Slew of Github competitors: Tangled, Cloudflare Artifacts, Netlify Source, Cursor Origin
- (55:55) - Git at Any Scale
- (57:14) - Lightning round
- (57:16) - npm.report
- (57:51) - Supplier Security Questionnaire, Andrew Nesbitt
- (58:58) - Everything I own, owned, Chaz Schlarp
- (01:02:33) - The sorry state of Skill distribution
- (01:03:46) - Conferences
- (01:03:48) - ZurichJS Sep 11
- (01:04:47) - React Alicante Sep 23-24
- (01:05:09) - Outro
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
1-vcarl: Thank you so much for joining
us for the August edition of This
Month in React as we recap what's
going on with React, React Native,
and generally on the web platform.
We are coming to you live
from Reactiflux, the place for
professional developers using React.
I am Carl generally known
as vcarl on the internet.
I'm a staff product developer,
freelance community leader, occasional
entrepreneur, sometimes consultant
here helping run Reactiflux.
And generally just trying to
keep this place valuable and
pro-social for everyone around it.
2-acemarke: And I'm Mark.
My day job is at Replay, where we've
built a time traveling debugger and
now an automated QA platform that
uses t , the time travel awesomeness
to help find bugs in your app.
Replay QA, please check it out.
And outside of that, I am still
doing an awful lot of Redux stuff
1-vcarl: Mm-hmm.
Cool.
Yeah August is often a slower month.
A lot of Europe is on vacation.
you know, kind of the end of summer.
It's the start of school.
So just often there's
not as much going on.
We do have a lot of new releases
or pre-releases, release
candidates to talk about.
Yeah.
Let's get going.
First off on our new releases, we've
got Waku 1.0 as a release candidate.
Yeah.
Waku, I don't know, I feel like I've
been thinking of it and describing it as
a new framework for server components,
and I actually went back and checked
how we've discussed it, and we've been
discussing it for three years now.
Like, three years is no
longer a new tool, you know?
But yeah, here we are at 1.0
with a release candidate.
2-acemarke: The, and, and, and
to recap Waku is a React server
components framework that's been
built by Daishi Kato, who i- who is
also the brains behind Zeustand and
Voltio and Jotai, and a slew of other
state management related libraries.
And the goal is to be a minimal server
components framework rather than something
like the, the all-encompassing Next.js
1-vcarl: Yeah.
So cool.
Love to see things get
to release candidates.
The fact that they've been driving
towards 1.0 for so long makes me
think, I don't know, makes me think
this is being thoughtfully approached.
Generally they, they, are very
thoughtful, so that's very cool to see.
2-acemarke: It looks like they've,
they've been doing some, some navigation
fine-tuning and improvements, but other
than that, it's mostly like we, we think
we've got it close to being final soon
1-vcarl: yeah, a- actually I'm
gonna, I'm gonna put out a little
call to audience, anyone listening.
If you have, like, built
something with Waku, I would
actually love to hear about it.
I don't think I know anyone
personally who has, like, any
kind of extensive experience.
So, yeah, if you have any feedback,
I'd love to hear about it in the
#general-tech channel or, you know, shoot
me an email to hello@reactiveflux.com.
Just general curiosity.
2-acemarke: I was actually just wanting
to try to look up download stats.
Like, I've, I've seen it for a while.
my general assumption is that it's
not widely used, and certainly
not in comparison to something
like Next.js or React Router.
1-vcarl: Yeah.
on that, I just checked.
It has 22,000 downloads per week
which compares to, you know, TanStack
React Query at 60 million n. So yeah,
definitely on the smaller side yeah.
Okay, moving on.
Another release candidate.
We have Pre Act 11 coming out , the
main thing they highlight is it's
now tree shakable which is a claim
that I always take with a pretty
substantial helping of salt.
Just never know.
I don't know.
There's so many ways to break tree
shaking, and we've been… libraries have
been working to be more tree shakable
for, like, six, seven, eight years.
So, you know, I don't know.
It's cool.
Love that.
That's great.
I hope it works.
But yeah, Preact is generally interesting.
It's cool.
Last month we were talking about React
alikes, and Preact is definitely the
original React alike, although it is
increasingly less alike as time goes on.
2-acemarke: Yeah, although it do- it
does say that the, the compat package
now includes the several other React
methods that have been added recently.
So while the semantics have diverged
somewhat over time, they are at least
still making an effort to try to keep
it relatively drop-in if possible.
MobX 7 came out.
it's funny because Mo- like MobX, I
think technically was, like the first
releases of it were actually a few weeks
before Redux came out back in 2015.
So MobX has been around for a while.
MobX 7 is primarily a cleanup
and modernization release.
They've dropped the legacy implementation
and now it now requires proxies to
actually track things, which has
always been the default behavior.
Improved some bundle sizes, some
tweaks to the, to the React bindings.
So still out there and
still being worked on
And on a much bigger note Next
16.3 is out, and the, the Next team
talked a lot about this release.
they seem to feel this is
one of the bigger releases
they've done in quite a while.
there's a bunch of dev improvements.
It's supposed to build faster, less
memory usage but it also has what, what
they're calling instant navigations
for s- better spa-like behavior as well
1-vcarl: Well, yeah, I saw they,
they had also done a AMA on Reddit.
Although I, I, I read through a fair bit
of it, and it was a lot of like, "Yeah,
we're working on caching. Yeah, big
sites are still hard." So I don't know.
It it, it was good to check in.
It was cool to see… You know, it was
a lot of big names giving, you know,
direct answers to questions, but um,
2-acemarke: There weren't a lot
of great secrets revealed in that.
1-vcarl: Right.
Yeah.
And it's just like it's been such a
consistent through line for two or three
years now of like, yes, caching is hard.
Local development is hard, especially
if you're dealing with, like,
100,000 pages being generated.
So, you know, it's just like , the
challenges and the stated
improvements have a certain
sameness to me over time for Next.
I'm su- You know, it does improve.
It gets better.
It, it… But, like, the challenges
are still pretty similar.
2-acemarke: And, you know, may- maybe
this is just a snide comment from the
gallery from someone who doesn't even use
Next at all, but it always… It, it's
felt like a little bit of that complexity
was sort of self-inflicted in a way
1-vcarl: Right.
Yeah.
I think we have another
thing to talk about later on.
I can't remember what this got in the
doc, but Lovable put out a blog post
about moving away from Next to TanStack.
And yeah, you know, it's, a, a lot of
it is like, oh yeah, we had performance
problems, and those performance problems
got resolved by moving to Vercel,
but we would, would like to have more
optionality f- than in our hosting.
So, you know, it's, the same kind of
complaints, and agreed that a lot of the
complexity seems kinda self-inflicted.
they keep trying to fix it by adding
more complexity, it feels like.
You know, it's, it's a continuous additive
system, and the fact that they keep
adding new things to try to address the
problems, and the root problems being
solved don't seem to be changing, makes
me suspect that the, they have gone deep
into the diminishing returns of additions.
I think it's perhaps time to subtract.
But subtracting is usually
a major version bump anyway.
Okay.
We have a new React Native version 0.87.
Man, I- every time we have got a release,
I miss having Mo out here because
he
2-acemarke: was just about to say that
1-vcarl: He's got such a good breadth.
Maybe I should bring him on as an
analyst or something like that.
But yeah, the, the big highlight here
looks, to me at least, looks to be that
they now have a strict TypeScript API
and type definitions are being actually
generated rather than hand-authored.
That's a huge… Going from
hand-authored types to generated
types is always a massive project.
It looks like this has been in the
works since about point or 0.80.
So, you know, that's seven, seven releases
now that they've been going towards it.
So, their strict TypeScript
API is now the default.
Not everything will be compatible, so
there's an opt-out, but they've stated
the intention of this - you know,
the, the opt-out going away over time.
2-acemarke: TanStack Table version nine
is out, and I believe I, I, I know I'd at
least pasted a couple of the prior blog
posts in the tech reads and news channel.
I don't remember if we actually linked
them in the, in the podcast last month.
Some of the updates they now have a
increasingly wide range of adapters
for different frameworks React,
Preact, Vue, Solid, Svelte, Angular,
Lit, Alpine, Ember and Octane.
So pretty much anywhere you're
using a framework you could use
TanStack Table if you wanted to.
They've made a whole lot of
improvements to performance.
They've pulled off some very nifty
JavaScript tricks to try to cut
down on memory usage rewritten the
internal state management, improved
type safety, and as we d- were just
saying, things are more tree shakable.
Wonderful
1-vcarl: Wonderful.
Yeah.
Tables.
Man, ugh.
I love that, I love that TanStack
has been so persistent at trying to
make a good table abstraction, but
I'm gonna be honest, I settled in,
like, 2017 of saying, like, "Nope.
There is no table abstraction worth
its weight in the bundle. I'm gonna
re- write every table from scratch,"
which has its own trade-offs.
You know, it's, it, then you have to
copy functionality and stuff is missing.
But, like, man, just, like, seeing this
release talking about how they have, like,
a new architecture that, y- you know, with
a record number of framework adapters,
it's just like, man, tables are so much
more complex than we give them credit for.
It's so hard to make a good table
2-acemarke: But I
thought coding was solved
1-vcarl: Coding is?
It's completely solved.
, it gets more and more solved the
less closely you look at the outputs.
2-acemarke: On a completely different
note we've talked in the p- past about w-
what was known as the records and tuples
proposal for the JavaScript spec, which
was supposed to add new data types to
the language that were gonna be deeply
immutable, and then you could just say,
"Is this value equal to the other?"
And the triple equals operator
would do a deep comparison.
That proposal eventually got withdrawn.
It's dead, it's gone, it ain't happening.
So there's now a new proposal
called composites, which is sort of
trying to solve the same problem,
but in a very different way.
Reading it, it looks like you create
these wrapper objects, and then
the wrapper objects will do the
value comparisons for you, I think.
So nothing immediately actionable
here, but it, it is interesting
to see that the design committee
champions are still trying to figure
out a valid solution for this problem
1-vcarl: Yeah, that's interesting.
Looks like it's kind of I'm looking
at this example in the actual spec,
the stage one draft spec basically
wrapping an object in a composite
constructor, and then, you know, you
do the same object keys and values
in two, and then do a triple equals
comparison, and cool, they're equal.
Th- so that's awesome.
That's interesting.
That's useful.
But yeah, stage one, that's
pretty far away from released
2-acemarke: And then we've talked
some previously about Solid 2.0 being
on the way and having a major change
in how it handles async, to how
that's baked into the signals graph.
They've officially hit
release candidate this month.
So there's the 2.0 RC announcement blog
post but then there's also some deep
dives that we'll touch on later that talk
in more detail about how the async graph
works and what that means for your code.
I continue to say that, like, Ryan
Carniato is probably doing some of
the absolute deepest research into
framework development and data modeling
and how to build better tools than
pretty much anyone else out there.
Obviously the React team put a lot
of thought into server components.
The Next team's putting a lot of thought
into, you know, building their framework.
Ryan's doing, like, the
bleeding edge research here
1-vcarl: I love that, so the
async lives in the graph is
for one, just a great header.
I love that as a thing
to unpack and understand.
But it's a, I, I wanna call out this
little parenthetical that says, "A
computation can return a promise,
parentheses, or an async iterator."
And man, a, promises versus async the
iterator is just so much more powerful.
So being able to support those, like,
you know, it's a little aside because
everyone knows and uses promises and
those, you know, everyone assumes those.
But man, I've been using async
iterators more and more lately,
and they're so powerful.
2-acemarke: I, I was, I was skimming
through the third of the three
explainer blog posts, and they
fleshed that one out in more detail.
And I think the example there shows
a component that, like, looking at
it, you almost wouldn't even know
that it would get updates because
it just works reading the data
1-vcarl: Yeah.
I've been using them mostly because
I have been doing all of my code in
effect the last couple of months, and,
like, or everything is a generator.
And generators can be iterated upon.
But yeah, like, you know, it, an
async iterator is basically a promise
that can resolve multiple times.
Like, ugh, that's incredible.
I don't know.
So just, like, So many times when you're
modeling something as an asynchronous
request, it may actually be better to
model it as a stream of incoming data,
and you can't do that with a promise.
You cannot have an, a
stream a stream of events.
So i- iterators are just, like,
this really magical in-between point
between events, like, you know,
event-driven architecture and promises.
anyway,
2-acemarke: Ben Lesh would like
to have a word with you about
RxJS and Observables at this point
1-vcarl: Ha ha.
Fair enough.
Yeah, super cool though.
Last thing I'll say on that is definitely
lend… early and prominent shout-out of
async iterators, I think, lends credence
to what you were saying about him being
on the cutting edge of the research here.
Like, yeah.
Everyone else needs to catch up.
go become familiar with async
iterators, because it will level
up your professional, capabilities.
Okay, moving on.
Bun has had a big release
2-acemarke: it's the single
biggest change log I've ever seen.
It's for what is technically a
minor release, except that they
also literally rewrote the entire
thing from Zig to Rust with AI.
Technically, there's no
breaking changes, so yeah.
1-vcarl: Yep, they've moved out every zig.
They're now on Rust.
2-acemarke: Deep cuts
1-vcarl: Deep cuts.
You know, you can't just put an
opportunity like that in front of me.
Yeah, I think this is super cool.
there's been a bunch of drama, a
bunch of words typed and spoken about
the Rust rewrite, and, like, I just,
I don't find that very interesting.
The most interesting thing I think
is that they used Basically a fully
automated workflow and the existing
test suite to say, "This works.
Go fix it so that it works in this
language instead." and then $160,000 in
tokens later, they had a Rust-authored
version that is apparently good enough
to release, and not only good enough
to release, but good enough to build
a, like, remarkable set of additional
features on as part of that release.
So, that's fascinating.
That's cool.
It's a little crazy to
see that much coming out.
J- Jared Sumner has always been, like,
kind of confusingly prolific at, in
terms of, like, level of output here.
So I don't know, just seeing him
become AI-enabled is remarkable.
But I was gonna say, oh, this is the most
important one, and then I'm looking at the
whole list and they're all pretty wild.
Like, bun.image lets you do a lot of
really powerful image manipulation
for the web natively, you know, just
within Bun, which is great, 'cause
I have previously done stuff like
that with FFmpeg and Sharp, and
those feel like they were written in
the early 2000s, because they were.
those have been around for a
long time because nobody wants to
rewrite them, because doing that
work in a way that is performant
and, like, usable is really hard.
So, you know, kudos for
shipping something like that.
I haven't played with it myself yet.
I want to.
But yeah, decode, resize, rotate,
encode JPEG PNG, WebP, GIF.
Yeah, just, like, all of the
image formats, doing resizing
and basic editing kind of stuff
is really, really interesting.
But then they've also got bun.webview,
which is basically like Playwright or,
you know, Cheerio or something, just
natively within the standard library,
which is wild and really helpful.
I haven't made use of this yet, but I
did go through… I have a skill that
I made for myself that is like, "Here's
how to set up a new project here.
You know, here's how to set up the
linting, here's what tools to use." And I
told it, "You should use bun 1.4 because
the web view stuff makes it really easy
to do end-to-end testing," allegedly.
I still need to validate this.
But they've also got, like, a markdown
parser and, like, a cron scheduler a
pseudo terminal so you can dri… You
know, they, they say, "So you can drive
Bash, Vim or whatever from JavaScript
without Node PTY." I've been rigging
up a bunch of, like, experimental
AI agent harness stuff, as part of
doing that, I've been writing a lot
of wrappers for Bash to be like, "I
need this service to be running in
the background while this server runs.
it's really janky.
I've had AI write a shit ton of, like,
bash-compatible things that are, like,
forwarding control codes, and making sure
output redirection works as expected,
and all those little subtle details.
So again, one more thing that is,
like, a pretty big load off of my
mind building something if I can just
ship it out to a standard library.
So anyway, yeah, it's
a massive change log.
Lots of controversial practices
involved in producing it and releasing
it, but mm, it's pretty cool.
End result is pretty neat
Cool.
And uh, man, another thing I've been
dreaming of for years and years and years,
GitHub is now doing a public preview
of stacked pull requests stacked PRs.
we've talked about this a couple times.
I'm not sure how widely familiar, you
know, the ecosystem is with stacked PRs.
This has been a, the way that I work
intuitively for a number of years at this
point, like probably dating back to 2019.
Where, like, work on something,
produce a finished branch, push that
up, create a pull request, and then
I'll … Most of the time, the thing I
just built was to enable future work.
You know, it was to unblock other
work that I mean to be doing.
So then I'll just take that branch and
continue working off of it, off a new
branch, and boom, that's a stacked, you
know, that's a series of stacked branches.
I'm, while branch A is being merged,
I'm working on branch B, and then,
you know, when branch A gets merged,
I push up branch B for review.
The, the revision here is that now you
can just push them all up and mark the
PRs as stacked on top of each other
and it will automatically do lots of
rebase and branch juggling for you.
Yeah, the challenge there is, okay,
you stack branches up like that,
like I was just describing, but
then when you merge them, you know,
the, the, the commit SHA changes.
You know, maybe you do a squash merge.
You know, maybe it's a, Anything
other than a fast-forward, and
you now have to do a rebase in
order to have the, have the branch
2-acemarke: Which means you have to
pull down locally, you have to do the
rebase, you have to, you have to do
some juggling locally, push it back
up, actually create things, and you
have to repeat that for every time you
do, you, you merge one of those PRs
1-vcarl: Right.
And so when you've got, you know, branch
A and branch B, it's not so much work.
But when you've got branch A that
drives branch B, that drives branch
C, that drives branch D, and you've
got eight people all contributing to
a shared code base, like that pull,
rebase, push cycle ends up being a
pretty substantial amount of work.
So it's really cool that
GitHub is now enabling this.
There's a, there's a pretty closely
related concept here as well called a
merge queue, which is basically like an
engineering practice where as part of
review, you know, you don't just mer-
you don't just merge when approved.
You don't say like, "Okay, this, this
PR is now approved for ship," whatever.
"Let's merge it now." it's part of
a queue, you know, it's in line.
So, just as a way to manage conflicts,
avoid doing rework because, you know,
it… When you ha- when the work
that's being merged into release
is more predictably sequenced, a
lot of benefits fall out of that.
And stacked pull requests are a
really interesting way to enable
a simplified version of that for
a, a larger number of people.
So I… This is really cool.
I'm excited about it.
I I'm gonna have to play with it.
2-acemarke: mean, it's, it's,
it's worth noting that on GitHub,
the unit of review is the PR.
Like, you can have as many commits as
you want, but what you see by default
is the final result on the branch, and
that is what we're all very used to
reviewing, and it's, it's what many
other GitHub-like tools have copied.
But there were, there have been plenty
of other code hosting and review tools
Gerrit, Phabricator, and others, where
the unit of review was the commit.
And so another part of this
usage-wise is how big of a unit
am I trained to review at once?
So, like, maybe you have your, you know,
your 5,000-line PR, but it makes sense
to review the changes in smaller chunks.
Well, on GitHub, it becomes difficult
to go through and review, like,
one commit at a time or something.
So either you say, "Here's the
whole thing. Looks good to me," or
you have to split it into multiple
PRs so that smaller chunks are more
easily reviewable, but then you have
to do the branch juggling dance.
1-vcarl: Yeah, and I guess I, I also
wanna say this was, like, Jared Palmer's
pet project while he was at GitHub.
2-acemarke: For about three months
1-vcarl: For the… Right.
So it appears that Jared Palmer
legitimately joined GitHub specifically
to ship this, got it into a state where it
2-acemarke: It's the meme.
It's the
1-vcarl: Yeah.
Right.
And then left, and then went… Yeah,
so anyway, that's, that's pretty funny.
Uh.
Okay.
Into our main content yeah.
Yeah.
Right
2-acemarke: Right so a few smaller items
from React core news-ish stuff this month.
There's a new API that's
coming out for React DOM.
It's a function called Browser,
which is intended to be passed to the
increasingly expanding use method.
So
it's use.
The idea is it re- the return
value of use will differ depending
on whether you're calling this
on the server or on the client.
So if you call it on… If you have a
component and it's getting rendered on the
server, in a server component or whatever
React will see that and essentially
leave a hole in your component output.
And then it knows that when this run, runs
again on the client, then it will fill in.
pretty much every code base at this
point has some form of a do this
logic only on the client util or,
or something along those lines.
This is essentially building
that functionality directly
into React DOM itself
Let's see.
We, we… I believe I mentioned last
month that, that there were updates
on the way for the React Foundation
website, and then they were also
talking about governance-related things.
They have shipped an update to
the website, so it at least looks
less AI vibe coded at this point.
still Looking and waiting for more
public details on what the foundation
is going to do long term, but
again, you know, bits of activity.
Things presumably are churning
away behind the scenes.
As, as we mentioned earlier, the
Next team did an AMA over on Reddit.
There's some discussion.
Some of it's the obligatory complaining
about Next.js not having proper
middleware and things like that.
I skimmed it.
Honestly, the biggest thing I got out
of it is that React 19.3 is probably
coming in the near future, and that
it should solidify the fragment ref
and view transition features which
have been in Canary for a few months.
So good to know that's on the way
And then the other interesting bit
was that the OXC team has shipped
their official support for React
Compiler built into Oxlint, et cetera.
And, and this is interesting
for multiple reasons.
So React Compiler itself was
originally written in TypeScript
and also required a Babel plugin.
And so it existed, but we've
spent all these years converting
our build tool chains to Rust.
Babel is slower.
People saw that build times got slow
again, and like, "We don't like this.
Can you just do it in Rust?" The React
team did an AI-assisted port of the
compiler logic from TypeScript to Rust.
That is in the React repo.
But then the question is: how will
that integrate with other build tools?
So other teams, Biome, OXC, Bun, et
cetera, have been taking the Rust
code and trying to figure out the
best way to integrate it, and the
OXC team in particular has actually
pushed ahead in a lot of ways.
They tried to integrate it once, and
then they decided that it made their
binaries too big, and they didn't
wanna ship that to everybody, including
people who don't use React at all.
So apparently they went
back to the drawing board.
They found some ways to optimize
the code, shrink the bundle size,
make it semi-optional maybe.
And apparently now the both the
build performance and the binary
size are good enough that they
felt ready to actually ship it.
So that, that support is
now baked in at this point.
And Biome is trying to do
some integration as well.
Bun 1.4 is supposed to have
React Compiler support.
So slowly but surely, these pieces
are all coming out in the ecosystem
in a much faster way, and so hopefully
that means that more projects will be
actually be adopting the compiler over
time and thus seeing whatever runtime
performance benefits you get from using it
1-vcarl: Should we go to Asteroid?
2-acemarke: Yes, the
asteroid not astro, asteroid
1-vcarl: Yeah.
Yeah.
Nolan Lawson, who is is somebody
who's been, like, individually fairly
influential on me as a developer I just
first encountered him 10, like, more, 15
years ago when I was still in college.
So it's cool to see his name still around.
he put out a great blog post
called The Asteroid Currently
Hitting Front-End Web Development.
, basically the same thing I actually
said on, at the end of our last episode
about impacts of AI on educators,
on content creators, especially in
the front-end engineering space.
And basically, you know, he's
highlighting that He says, "A lot of
the educators I admire in the front-end
web space seem to be either bowing
out or dialing back their efforts."
And like, yeah, Axel Rauschmeyer,
hugely influential blogger about
the standards process and, you know,
JavaScript itself as a language.
Salma Alam N- Naylor, well, Selma
and Josh we talked about specifically
at the end of the last episode.
And, and then he calls out, too, that,
like, Kenzie Dodds, Addy Osmani, Rachel
Neighbors, Lydia Hallie have all moved
more from front-end development into,
like, AI agents software development.
Which I, which I think is fair.
You know, I don't, I, I, I think
comparing people stepping back
versus staying on the cutting edge.
for a long time front-end was the cutting
edge, and then it was, like, React Native
and where are we gonna put React next?
And so now it's not as much that.
Now it's AI and how do you build stuff?
How do you build a software factory?
, 2-acemarke: even that is a theme
we've touched on for a while.
I mean, swyx used to be part
of the React ecosystem space.
He was a mod on the, you know, in
the subreddit, did a lot of talks,
and then, then he got involved with
Svelte, and then he pivoted to running
AI conferences and, and podcasts.
, we've even talked about, like,
the energy at React conferences
seems to be down, whereas the AI
conferences have all the energy.
So, like, there,
1-vcarl: Right
2-acemarke: like, a lot of trend here
. 1-vcarl: This post from Nolan Lawson,
he talks about the future of front end.
And I'm just gonna read a couple of,
like, high-level points he makes.
The front end is less risky
to just hand to an agent.
Developer experience is
becoming less critical overall.
Standards will catch up.
I think this is interesting.
I, these rhyme with points of contention
that I've seen in the industry
for essentially my entire career.
Like, you know,
is front end… Right.
Front end is easy, and
developer experience isn't
worth the time investment.
, I wanna call this out.
He says, under developer
experience becoming less
critical, "The agents know React.
For better or worse, React is heavily
over-represented in the training weights."
And again, like, something we talked about
last episode, I believe, was Aiden Bai put
together a benchmark of not just React,
can it make something functional, but
how well does it actually execute React
best practices across different models?
2-acemarke: they know what
React code looks like.
They don't really know how
to write good React code
1-vcarl: Right.
So
2-acemarke: They know what
bad React code looks like
1-vcarl: Yes, bad React code is heavily
overrepresented in the training set, but,
I used to, I used to work, when, when
I was more earnestly working full time,
I went to a lot of different companies
for, you know, a year, six months, a
year and a half, and the reason I was
able to be very successful at that is
because every company used the same set
of very bad practices that represented
a fundamental misunderstanding of
the advantages that React offered.
And so it's like, cool, I understand
those, let me come in and fix this
incrementally one thing at a time, and
the improvements are so mind-blowing to
you as somebody who doesn't understand
the tools you're using, that, you
know, great, cool, great, awesome.
Who… Lovely performance
reviews, yada, yada.
I both understand where
he's coming from on this.
there is less risk in f- the
client versus the server.
If you fuck up data on the client,
like, you just, you know, pull f-
from scratch from the back end.
But if you screw it up on the
back end, like, oops, data loss.
Oops, you know, security vulnerability.
So it, you know, these are both true,
and I think, like, fundamentally
missing some kind of point.
So I don't know, it talks about the future
of front end and front-end education.
I think there's still a lot of room for
human cognition as steering input to
guide agents that, you know, they may
be individually capable of achieving,
you know, X, Y, Z, maybe even better
than I can, but they need to be told
what the constraints are in a w-
in a manner that is, you know, y-
helpful to guiding them to waste less.
You know, like, rework is so costly that
if you, if I, as the intelligent human
with experience using these tools and
knowing, you know, what has downstream
effects six months, a year, five years
from now, then yeah, I think there's still
a lot of room for expertise meaningfully
2-acemarke: when I wrote my own AI journey
emotional blog post back in April, one
of the points I made was that I did…
Once I got past, "I will never use this,"
and actually started using these tools,
I've been able to use them effectively
because I already know how to write code.
I already understand what
good code looks like.
I know how I want to do things,
and now I'm just trying to speed
up the process of doing the work
that I already intended to do.
or using the tools to give me a
range of options, and then I make the
decision based on which one actually
feels like it fit, fits the best.
but then that brings up all the, and
all the usual questions of, well,
how do you get all this experience?
Well, I did it for 20-plus years by hand,
and now I'm reaping the benefits of that.
And how do others gain that
experience in today's world?
I don't know.
I'm not in that position at this
1-vcarl: Yeah.
You know what?
I think they learn it, I think they learn
it essentially the same way that I did.
Fucking trial and error.
Like, I have a, I have
an associate's degree.
I have nev- you know, I've taken
one year of computer science.
Like, I was not taught these things.
I learned them largely
through trial and error.
You know, you join a company, you ship
some code, you have to deal with the
consequences of the code that you shipped.
I, there's no substitute for experience,
and it is easier than ever to go
from non-functional to functional.
And once you have to maintain a functional
thing and keep it operating and expand
on it and improve upon it, I feel like
the lessons aren't that different.
I don't know.
At the end of the day, I think
it's, it comes down to how well
can you ask questions of this…
You know, we're all gonna be
managers in the, in this AI world,
2-acemarke: So a lot of the
discussion around this whole
direction has then been, yeah, like,
what… where is the place for us?
What does that mean for our careers?
How do we feel about this?
So Scott Tolinski uh, one of the hosts
of the Syntax.fm podcast with Wes
Bos did some work within the last few
weeks that really touches on, on this.
Scott had his own AI psychosis
phase some months ago.
And coming out of it, he's like, "Okay,
This has affected how I feel, like,
literally on a daily basis. I wonder how
other devs have been going through this as
well." And so he put up a survey online.
Has been trying to gather as
many respondents as possible.
I think he's up to 7 or 8,000
respondents at this point.
So you know, a f- fairly
decent sample size.
And it, it's, it's relatively
short, but it asks questions like
do you feel like your skills are
eroding based on your AI usage?
How many times have you found
yourself staying up later than you
intended because just one m- just
one more prompt, one more prompt,
Or, you know, sort of the slot
machine effect of just asking it
to do, you know, some more work.
So he gathered up the results,
and I believe his wife is
actually, like a, a psychologist
with, with a, with a doctorate.
And so he was having her work
through him on some of the
statistics and the analysis on this.
And he also was reaching out and doing
some video interviews with a number
of people to follow up and get some
ac- you know, some more direct, you
know, r- real-life anecdotes and data.
So I actually did a video
with interview with him, and
we, we had a good discussion.
He pulled all this together into
a half-an-hour YouTube video where
he talks about his experience, his
research, and brings in video clips
of a bunch of people including myself.
It's a really good video.
I, I strongly encourage people to
take the time to read through this.
The end, like, the end bit
of it is basically take care
of your mental health, folks.
Like, don't let this, rapid pace
change in the world get to you.
Take care of your mental health, establish
your boundaries, and then go from there.
1-vcarl: Yeah.
Yeah.
Very important.
I think at the intersection of that,
take care of yourself, understand
your boundaries, hold yourself to
your boundaries, which is hard.
staying within them for a long
period of time is really hard.
2-acemarke: I know what the right
things are and I am not the world's best
poster child for sticking with them.
Do as I say, not, not as I do
1-vcarl: Right, right.
and I wanna connect that back to this,
you know, asteroid hitting front-end web
development and educators falling off
and no longer producing output at the
same level that they were in the past
A lot of my, I think a lot of my energy
in producing this podcast, in running
Reactiflux, in contributing to the
ecosystem has been, especially the last
five years, has been very much rooted
around what can I do to not burn out?
So, you know, it's like the reason this
is a once a month podcast instead of
weekly or daily or whatever is 'cause I
would burn out if I did anything else.
Like this is enough effort for me and
this is already once a month for an hour
plus prep is already disruptive enough to
the other things I want to do in my life
that I can't do anything more than this.
2-acemarke: Ditto
1-vcarl: Okay, we've achieved
some small level of success.
We have several hundred people
listening every month, which is
lovely and great, but like, you know,
on the grand scheme of things like
this is never gonna pay my bills.
This is never gonna be a full-time career.
And like, you know, whatever, that's fine.
That's okay.
That's okay because that's what
I, I built it not to be that.
I built it not to take over my life.
I built it to let me do it at
my leisure, at my convenience.
And I don't know, you know, in some
ways, like, a personal life philosophy
of mine is to like be inexorable,
just like, th- just be unstoppable.
Like you don't need to be the fastest,
you don't need to be the smartest, the
most resilient, but like just keep going.
If you, if you're going in a direction,
just steady advances incrementally.
And so like, you know, I'm not, I,
I'm never gonna have hundreds of
thousands of social media followers and
you know, tens of thousands of hours
listened across multiple platforms.
But like, you know what?
When the other people
burn out, here we are.
know, other people do these content
projects for a year, two years,
three years, but like Reactiflux,
we've been around more than 10 years
now and I've been helping run it
for a lot of that, most of that.
I've been a moderator or an admin for
10 years now, 10 and a half years now.
So I don't know.
That's, I think that's, that is
an attitude that is not widely
rewarded in tech, in tech generally.
You could say some other things
about different subdivisions there,
but I think it's, I don't know.
I think it's important for mental health
and pers- physical health as well 'cause
burnout is not just a mental health issue.
You can have serious physical
health consequences from that.
Anyway, yeah, I don't know.
I'm gonna trail off there.
2-acemarke: Yeah.
So here's sort of the flip side
of that keep persisting thing.
I mean, we, we listed a number of people
who have made the decision to step back
because they're feeling burned out or
feel like the, you know, the audience
and the career that they'd built
just no longer exists at this point.
So Josh Goldberg, who has been a
very prolific open source contributor
working across multiple different
linting and build tools recently just
announced that he's stepping back
completely from open source maintenance.
I actually talked- had talked to him live
just before he posted this, and he, he
told me this was where he was headed.
Some of it is life changes.
He's, he's had a number of stuff
going on in his personal life that
have taken up time and energy.
Some of it is getting very
frustrated with AI PR spam
and, you know, just not wanting
to deal with yet another seemingly
plausible bug report that turns
out to be complete nonsense.
And some of it is just a desire to
literally go out and touch grass
and do other things with his life
at this point.
that's also an entirely valid set
of decisions, and he said he's
ha- essentially handed over all
of his projects or they're in
maintenance mode at this point.
He's still working.
I believe he's at Sentry at this point,
but he's stopping open source work.
And so, like, I'm happy for him
in the sense that I want… He's a
good- he's a great person, and I want
him to do what's best for his life.
It's a little sad in seeing someone
who has been involved, you know,
saying, "That's, that's it for this
phase of my life," and stepping away
1-vcarl: Right.
It, it's sad to me because he's a friend.
I consider him a friend.
He stayed at my house once
because he was passing through
and needed a place to crash.
I… He's a lovely person
He's so kind and so generous, and so
purely wants to do good that it sucks.
it makes me genuinely sad to see him
take a s- need to take a step back
because he can't do it all, you know?
Because he, nobody can do that all.
It's too much.
You can't work full-time and have a
engaging, rewarding personal life and do
these side projects, and also organize a
conference, 'cause he was doing that, too.
So yeah
2-acemarke: I mean, I've,
I've had my own thoughts.
Like, I, I have no plans to stop
open source work anytime soon.
In fact, I've actually got uh, like I
said, we said last month, I'm trying
to push through a big new React Redux
feature, and I've got a bunch of plans
for what will hopefully turn into our
next set of major version releases.
But you know, purely mathematically,
the day will come when I no
longer do Redux-y things.
It might be 'cause I'm 83 years
old and no longer have the
mental capability to do it.
And, but, like, mathematically
I'm gonna stop eventually.
It's just a question of when and why,
and what am I doing with my life?
1-vcarl: Yeah Tough.
I don't know.
I've wrestled with that a lot.
What am I doing with my life?
What is my life?
Who am I?
What do I care about?
What are my values?
2-acemarke: Why are any of us here?
1-vcarl: Why are any of us Why
2-acemarke: on that note I'll,
I'll toss out three other links.
I'm not sure there's necessarily a
lot of discussion, but they, they
fit very neatly under this category.
a group calling themselves the Software
Stewardship Lab is trained to help
improve open source sustainability.
And ironically, when I was on vacation
in Scotland earlier this year, I
actually happened to talk with some
of the people who apparently were…
They must have been doing some of
the planning for this at the time.
Daniel Roe, who's the leader of Nuxt,
you know, the, the next equivalent
for, the Vue ecosystem is involved.
Vlad Harbuz, Andrew Nesbitt, who's
been doing massive research on
packaging ecosystems uh, Matias
Capelletto, who's involved with the,
the npmx project, Miranda Heath,
who's been doing research on burnout.
A lot of, again, very, very good
people who care deeply about
open source and community as a
concept are involved in this.
I'm a little unclear on how they're hoping
to improve things, but I highly, highly
approve of the concept, and these seem
like the right kind of people to be doing
thinking and research I read a really,
really long blog post, my favorite kind
that covers a number of things related to
AI migrations and software craftsmanship.
It's long enough that I don't
remember what all was in here, but
it was a really, really g- good
post and worth taking a look at.
And then James Garbutt, who's involved
with the E18E Ecosystem Cleanup
Initiative, wrote his own post on
humanity in open source, and some of
his points are that, yeah, we're, we're
getting swarmed with AI PRs and issues.
Open source is about more than
just… Like, the construct of
open source is about more than just
licenses and releases, et cetera.
It's about the communities that are
getting involved, and it would…
And then there's also the questions
of, you know, how do we keep building
those communities, especially if
people keep getting burned out?
So he has s- several different
thoughts on trying to manage that
1-vcarl: Yeah.
Okay, at the mention of
communities, I wanna jump in.
- we're talking about, communities
maintaining shared infrastructure
is how I'm gonna frame this, you
know, humanity and open source.
Do you know how many different
communities are maintaining the
shared infrastructure that support
every aspect of your basic life?
2-acemarke: Where's
1-vcarl: I think…
Yeah, right, but y- right,
okay, so there's XKCD of all
the stacked, you know, boxes
with, like, that fragile thing.
But, you know, like, you know what?
Like, how do your lights stay on?
How do you get hot water?
You know?
How do you stay cool?
How do you get groceries?
Like, each of these is the
output of a shared infrastructure
being maintained by a community.
You know?
Okay, the s- the, the, the power that
might be, the community there might
be a regional monopoly as dictated
by, you know, legislative priorities.
but, like, th- th- I guess
that's how I wanna frame this.
Like, I think we are exceeding
the type of human scale.
You know, this is like the
Industrial Revolution of software.
Like, it used to be all handmade
parts that were not interchangeable.
Th- and we've been moving more
and more towards interchangeable,
fully automated whatever.
And, like, yeah, for better and for worse.
Like, if you take that lens of
handmade versus scaled, you can
apply that to almost anything.
Like, I occasionally like to bake bread.
I also buy store-bought bread because it
keeps longer, and it keeps longer because
it's a fully automated system that has
been refined for 150 years because people
need bread, and not everyone has the
available time and resources to bake it.
So, you know, like I, I love to think
about water, water is a crazy, when
you actually look into the, like,
societal level engineering projects.
So like control of the flow of
water is a shocking percentage of
human effort over the millennia.
Like not, keeping it
within the tolerable bands.
You have to have enough to keep everyone
who lives there alive, but not so
much that it washes their houses away.
And like managing that is a
preposterously large project, and when's
the last time you thought about it?
So like that's… I think open source is
now moving more in that direction, where
it had been very human scale of like, I
know the 15 people who are making all of,
you know, making this whole thing work.
And now we're starting to go into
a place where there is enough
automation in generating and
consuming code that that scale of
investment no longer really works.
Another useful lens here is
like Etsy versus Walmart.
Like I can go to Etsy and I can buy
picture frames or, you know, a pin
or a sticker or a shirt, and that
was probably handmade by somebody,
hand designed by somebody, and I'm
gonna pay a little premium for that.
But like most people don't
actually care that much about
where their shirts come from.
They don't care about the manufacturing
process of, you know, how this,
was this picture frame made with
sustainably grown wood, or is it a
composite made out of sawdust and epoxy?
Like most people don't care.
It looks good on the wall.
So that, to me, is a really
fundamental lens here.
It's people who are used to being
very close to the production grating
against the automation of what they
have taken great pains to do well.
And neither side is wrong.
Both of them are fully correct.
2-acemarke: So partly angling off
that, and this was actually in
what passes as a script over here.
Two more stories of migration
that circle back through the AI
aspect, the frameworks aspect.
Cursor just got done migrating their
entire system from Solid to React, and
they talked some about it, and one of
the things they said is, "Well, the
agents are more used to writing React.
They actually make a lot of mistakes,
but at least we're familiar with those
mistakes, and they're obvious to us now,
and we can control and correct for those.
Whereas with Solid, they just sort
of got confused most of the time."
so that… There was, there was a lot
of debate back and forth on Twitter.
A, a lot of quote tweets and, and
some discussion from the Solid team
saying you also didn't ever really
give us much of a chance, but yeah.
So there's, there's its own drama there.
1-vcarl: Yeah.
Certainly no, certainly no
part of this was because Lauren
used to be on the React team.
There's probably no bias there.
Yeah.
This is such a shady tweet.
Like, "Much love to the Solid team
and congrats on launching Solid 2. We
just finished moving away from you."
Like, that's some hella shade to throw.
2-acemarke: And then we mentioned earlier,
Lovable talked about having migrated I
think their own actual system away from
Next.js and over to TanStack Start.
And I, I, I know they switched
their project setup from whatever
the previous was to TanStack Start.
I believe this is separately saying
they switched their own infrastructure
to be built on TanStack Start instead.
I love a good migration post.
This goes into a lot of details, and it
does say that they did some of that work
with AI tooling further down once they
had identified some of the constraints
we could have spent a
bunch of time on this.
I think we've probably gotten far enough.
We probably shouldn't spend time
on this, but sort, sort of a meta
point and, and one of the things we
keep circling on is you can switch
very easily from tool A to tool B or
language A to language B at this point.
You say, "Here we've got this thing.
This thing works. Make it work in some
other tool set entirely," and if you've
got enough tests, enough tokens, enough
time, then it pops out on the other end.
Having said that, I do actually want
to bring up one more set of framework-y
things because I think this is fascinating
reading as a person who spends too
much time caring about frameworks.
I mentioned earlier that Ryan Carniato
and the Solid team have been doing a
bunch of bleeding edge research especially
into how the entire signals data graph
can encode the asynchronous of the data
in there instead of needing to, like,
separately keep track of promises or,
you know, loading flags, et cetera.
And so they've put up a, a series
of three posts that go into the
details on what that means in
practice when you use Solid 2.
I thought they were
fascinating reading myself.
1-vcarl: Our last main topic before
we go into what are allegedly
short asides, lightning round.
The general unreliability
of GitHub lately lately.
they Put out a blog post talking
about the outage on August 17th.
And like, yeah, you know what?
Like, they're not…
They're barely holding one nine
of availability lately That ties
very closely to the rise of agentic
coding and the sheer volume of
commits that are being pushed,
2-acemarke: they've published a number
of stats in the last several months
about how the number of PRs and commits
and API calls has just absolutely gone
through the roof in the last few years.
1-vcarl: Like 10X, 20X
2-acemarke: a large multiplier
1-vcarl: Yeah, fair.
Yeah.
there are now more and more people
throwing out GitHub competitors,
which I think is interesting.
There's Cloudflare, Netlify, Cursor.
oh, wow from chat, "GitHub reported
one commit per millisecond."
2-acemarke: initially read that
as one commit per, from Microsoft.
I'm
1-vcarl: Yeah, me too.
All it takes, one commit for
Microsoft to take down the system.
The commits are coming
from inside the house.
Okay, sorry.
But yeah, so there's now…
there's a combination of factors
that are making people start
to put out GitHub competitors.
Okay, obviously we're in the middle
of discussing the significant
outages that GitHub has been
having for a number of months now.
But there's also, we don't
know how to work anymore.
We don't know what the best way to…
Uh, Well, okay, we never knew what
the best way to work is, but we had
at least settled on pretty widely
adopted patterns, which GitHub, you
know, codified and then led in a
2-acemarke: You have, you, you have
a trunk, you make a feature branch,
you work for a few hours or a day,
you push a PR, a teammate reviews
it, CI goes green, and you ship it
1-vcarl: Right.
there's a lot of assumptions about
how you use Git in that workflow.
And so, like, you can use Git in
different ways if you were to so choose.
Uh, I actually re-
2-acemarke: was a thing back in the day
1-vcarl: Yeah, and I actually have
moved uh, one of my projects more
towards a Git flow type thing, where
you have a periodic release, and you
cut an RC, and you do user acceptance
testing on the uh, on the release
candidate, and you ship that artifact.
There's an explosion in exploration
of new ways to work with code and new
ways to collaborate with others around
code that I think is driving some of
this curiosity to try alternatives.
I'm personally very curious about trying
to self-host some infrastructure here.
I don't know.
Maybe this is me b- spending five
years independent and not working
with companies, but like, man, there's
just much unexplored territory now
2-acemarke: there was a really
good discussion over in swyx's
Discord just a couple days ago
with a different but similar theme.
Some of it was the debate over, "Wait,
you guys are still reading code?" but
then that also ties into, "Wait, you
guys are st- like, like who's using
an actual IDE to do their work?"
Versus this new breed of agentic swarm
management tools, where what really
matters is you have a chat screen and
a dashboard of all the agents and the
work trees in flight, and maybe it's
got like an integrated diff viewer, but
what really matters is, like, the task
management rather than, like, I need
to have the code open so I can type.
1-vcarl: Right.
the way I have been working is very
acceptance-driven of just, like,
does this achieve the goal I set
out when I started this project?
And I don't really review the PRs as much.
I do quick , sanity checks of,
like, you know, is this 15,000
lines when it could be 2,000 lines?
But, you know, like, very high level.
I'm not really understanding the…
You know, I, if I wanna understand
something about how the code works or
how the code is structured, like, I ask
the agent, 'cause the agent wrote it.
yeah, I don't know.
Dashboards and such, I think is…
that feels not quite right to me.
That feels like project manager kind of
capacity more than, like… I don't know.
These, like, task tracking is different
from did you build the right thing?
What's underway is different from
are we working on the right things?
So, just thinking about it through the
lenses of different professional titles,
like software engineer versus, like,
manager versus, like, director of product
or project manager, program manager.
Like, all of those needs of establishing
what the space we're working in is, what
other solutions have other people tried?
What, what are we ruling out?
What is the actual need we're solving?
Are we achieving that need?
Yeah, that's all the same.
Now that code is no longer the
primary thing that I want to
read in order to understand the,
the answers to those questions.
Yeah.
I don't, I think we're, I think we gotta
figure it out, kind of from scratch.
2-acemarke: So point is, there's an
awful lot of experimentation going
on in how we as developers are, what
tools we're using to do the work
and what the workflows look like.
And so then between the massive increase
in commit scales and, you know, the,
the changes in those workflows, we're
seeing a variety of different hosting
tools come out that, you know, either
just, hey, you can have your Git
hosting not on GitHub or, but also po-
possibly make it more agentic friendly,
1-vcarl: Yeah.
2-acemarke: whatever that means
1-vcarl: Interesting.
I'm, I'm exploring some stuff
around this area as well.
I'm going to be coming at it from
a very different direction from
all of these places, which are
still fundamentally anchored around
software as a service published on
the cloud which I think is limiting.
But yeah.
Two that I wanna shout out.
Tangled.org is pretty interesting.
They're doing… They're trying to
do essentially GitHub on at protocol.
2-acemarke: no
1-vcarl: So it's, you
know, it… That's cool.
It's a decentralized social media
platform, and they're putting basically
the social components of GitHub
onto that decentralized protocol.
So awesome.
That's awesome.
That's very cool.
Cloudflare is also doing a,
yeah, versioned storage that
speaks Git, is their headline.
We had some others in the notes from
Cursor and Netlify, but I wanna be
honest, I don't, I don't feel like
either of those are in the right place
to successfully execute on that vision.
2-acemarke: Mm-hmm.
I will say that this article
on scaling Git was fascinating.
there's been a lot of efforts
over the years to make Git scale.
Microsoft has done a lot of work
on, like, virtual file systems
and improving algorithms inside of
literally the Git implementation itself.
This one's more focused on
the hosting side of things
1-vcarl: Yeah.
And okay, this is why I'm skeptical
of software as a service cloud-based,
'cause, like, that's the problem.
Like, Git is a decentralized
system, you know?
You can just add a remote,
and it… Like, you push.
It's exactly the same.
yeah, if you're dealing with pushes
from literally the entire world,
that's really hard to optimize.
But, like, I dream, I hope, I wish
that at some point we will get
to a state where more people can
have, you know, world accessible,
safe compute that they control.
Like, I have a network
accessible storage here.
It technically can run a Git server.
Like, there's no reason I couldn't use
that as my primary store, and then,
like, make that available to some other
tooling that is aware of that storage
and does collaborative features on top.
When you distribute stuff like that,
you don't have to worry about load at
any individual site anywhere near as
much, which is what this Git any, any
scale kind of post is talking about.
Anyway.
some lightning round whatever.
I saw a fun thing, npm.report.
It looks like an interesting way
to just get, like, a very brief…
I don't know, this is, this
is maybe a very early project.
Just looking at some of the numbers on
the landing page Well, it's certainly
not ingesting all of npm to do this.
But yeah, it's interesting.
It's doing supply chain trust signals
for npm organizations, so the audit,
visualize, share, track over time.
Uh, It's an interesting idea.
I'm not quite sure if the execution
is fully able to execute upon the idea
it has, but it's looks interesting.
Supply chain management auditing
is so in vogue right now because
it doesn't work very well.
2-acemarke: So I, I mentioned
Andrew Nesbitt earlier.
He's been blogging for, for a while
on package management ecosystems.
He's, he's probably the world's
foremost expert on all the world's
package managers out there, and has
put up a lot of blog posts on, like,
how they work internally, where
they're flawed, all these other things.
He's also written several
satire posts on his blog.
, he's written some fake articles
about fake AI-driven CVEs
slipping through the chains.
he did this one a supplier
security questionnaire.
You know, the kind of thing that,
like, a, a company security office
would send out to their dependents,
except this one's clearly being
sent to an open source person.
And the questionnaire just gets more
and more absurd on the requirements
that they're placing on this
unnamed open source maintainer.
And, and that, that's sort of what happens
when the legal compliance side of things
wants assurance that your supply chain
is secure, and two-thirds of your app
is just we installed this NPM package
1-vcarl: Yeah.
Cool.
Nice.
Love that
Okay.
Well, continuing on our security thread
there . I read a really great blog
post called Everything I Own, Owned.
so this person, Chaz Schlarp, put
out a blog post about pointing Claude
at various physical devices that he
literally owns, that are physically in
his possession, and just saying like,
you know, "Hey, can you hack this?
Can you get control over this?
Can you put a custom firmware on this?"
and the answer resoundingly is yes.
2-acemarke: Nice
1-vcarl: you know, hacked his own
webcam a- alarmingly hacked it
in such a way that he was able to
turn off the recording light which
ideally should not be possible.
Ideally, that should not be a
software controlled feature.
It should be electrically
impossible for the camera to
record while the light is off.
Oops, this one could.
Also hacked his monitor.
And I… Something I appreciate is
for each of these devices, he puts
up a GitHub repo of the new firmware,
how long it took Claude to figure
it out, and how many prompts from
him it took Claude to figure it out.
So this, you know, the webcam
was three and three quarter hours
of Claude time with 33 prompts.
His monitor is hour and a, hour
and 15 minutes with 13 prompts.
A microphone was four hours, you know,
four hours and 15 minutes with 32 prompts.
I think this is really fascinating from
a couple of different ways because to
tie it into a like macro, huge question
of ownership conversation that I've been
hearing about for the right to repair.
Like most things don't let you repair it.
They don't let you, you know,
access any kinds of internal state.
And so like now that these AI tools
are good enough at reverse engineering
and cybersecurity stuff to just hack
it, like, hmm, that's actually pretty
interesting for right to repair.
Like you know, to the extent that
rules and policies are only as good
as your ability to enforce them.
Like oops, they can't enforce their
own security practices because it used
to just assume that it was too hard
to flash a custom firmware and now
it's actually not that hard as, if
you know generally what you're doing.
2-acemarke: Or in a lot of cases, if
you don't know what you're doing or just
willing to tell Claude, "Try harder."
1-vcarl: Right.
Right.
here's a fun one.
This is a mini key light.
So I think it's, you know, it's like for
video production, it's just like a little
controllable two by three inch light.
And he says, " This one turned out
way more interesting than I expected.
It's the only one with meaningful
firmware integrity protection.
It signs the firmware updates with ED25519
and a hash of the firmware payload and
rejects firmware that doesn't validate.
Unfortunately, while that's an
improvement, it protects the
firmware ex- at exactly one
point in time, during updates.
I asked Claude to look for an exploit
that might enable, you know, other
attack surface, and it found an HTTP
post request that drops a payload
straight into the internal UART which
includes a memory poke command."
So it, you know, it's got signed
verification
2-acemarke: Change this value."
1-vcarl: Yeah.
So it's, it, it has ostensibly
update security, but it also has
an HTTP endpoint that will let you,
like, arbitrarily revise memory.
He says, "This means a single HTTP
post of ATSC equals," and then two
hexadecimals comma-separated values,
"turns the signature check into a no-op,
and we can freely update the firmware."
So it's just like, man, that's crazy.
That's great.
2-acemarke: you tried
1-vcarl: At least you tried.
Yeah, defense in depth, it's really hard.
I don't know, that's really interesting.
Like, if we own, if we more meaningfully
own the ability to control what the tech
in our rooms is doing, that's powerful.
I appreciate that.
We should have more of that.
Final AI security adjacent thing
from the Trail of Bits blog.
The Sorry State of Skill Distribution,
talking about how the skill
marketplaces for AI agents are
full of malicious skills that will
exfiltrate your, you know, credentials
and blah, blah, blah, blah, blah.
Yeah, so don't download
arbitrary skills without reading
what they're gonna be doing.
You know, this is just an extension of
I don't know, running untrusted code
is never good, and running untrusted
skills that will have the ability to
run untrusted code on your hardware is
even worse, ' cause these are smart.
Yeah, reminds me too, I, I just learned,
this happened last month, but a certain
AI platform controlled by a person whose
name I don't like to uh, give airtime
was, it turns out the whole agent itself
was uploading all of the directory
that you ran it in with no control.
So it would pull every, every
file in there and just dump it
into a remote GCP container.
So, like, state of security right now
in the AI w- world is pretty rough.
Most people are being very sloppy
about it, and if you are riding
the cutting edge, the odds that
you run into something that will
aggressively attack you is pretty high
.
Oh yeah, Mark, tell us
about this conference
2-acemarke: Yep same two I mentioned
last month, and conveniently
they're the… I, I know about
them because I will be speaking at
both of them in the next few weeks.
ZurichJS is happening, I believe, on
September 11th in Zurich, Switzerland.
I said it last time, I'll say it
again, because he r- especially
because he ran across the transcript
and thought it was very heartwarming.
Faris Aziz is a good, close
personal friend of mine.
He's running this conference.
He's been running the ZurichJS
meetup for the last year or two.
This is the first time conference for
them and I know how much effort he
has been putting into putting this
together, from selling tickets to
doing outreach and getting sponsors
to building an entire conference
management platform from scratch.
Faris is awesome.
This will be a fun conference.
The speaker list looks great.
I'm looking forward to seeing a
lot of good, good friends there.
If you are anywhere in Europe or
even not in Europe, consider buying
a ticket and joining us there.
It'll be great.
similarly, React Alicante
is in Alicante, Spain.
I believe that's around
September 23rd, 24th-ish.
That's also been a lot of fun.
it's a very well-run conference.
Another great organizer, Victoria.
it's a good conf- there's
a lot of good people there.
Come join us.
Hang out.
Talk in real life.
It's a thing
1-vcarl: Yes, I can confirm that Mark is a
lovely person to go to a conference with.
Cool.
All right, that's all we
got for you this month.
Thanks for sticking around an extra 25
minutes past our… Well, I'd say past
our typical end time, but it's not like
we've ever hit that, I think, this year.
we'll be back next month.
Maybe not on the last Wednesday,
'cause it's the last day of the month.
Or we'll be back in your podcast feed
just as soon as we can after we record.
Yeah, thanks so much.
If this is a podcast that you
find valuable I'd actually just
personally love to hear it.
If you shot me an email to
hello@reactiflux.com and said something
about how this has influenced the
way you think or do things, that
would be personally meaningful to me.
Or give us a review.
Tell somebody else that you
know about this podcast.
That would all be very helpful.
We have a sponsor for next
month, which is great.
yeah, so that should cover most of
the costs of producing it for the
year, I like not paying for it myself.
cool.
Thanks so much.
See you next month.
2-acemarke: Take care