This Month in React

Transcript and show notes

TMiR on Bluesky

  • (00:00) - This Month in React - November Episode (SM)
  • (00:13) - Intro
  • (01:00) - New releases
  • (01:04) - [BetterAuth 1.4](https://www.better-auth.com/blog/1-4)
  • (02:47) - [Immer 11](https://github.com/immerjs/immer/releases/tag/v11.0.0), [RTK 2.11](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.11.0)
  • (06:00) - [Storybook 10](https://storybook.js.org/blog/storybook-10/)
  • (06:22) - [0.1 version of Remix team’s “event interaction” package](https://github.com/remix-run/remix/tree/main/packages/interaction)
  • (08:04) - Main content
  • (08:08) - [Ecosystem panel](https://gitnation.com/contents/panel-discussion-the-future-of-react-and-its-ecosystem) discussion of React Foundation at React Summit NY
  • (14:46) - React Concurrent Stores: [Polyfill](https://github.com/thejustinwalsh/react-concurrent-store), [React-Redux POC](https://github.com/reduxjs/react-redux/pull/2263)
  • (17:52) - React Router and transition usage
  • (18:08) - [Matt Brophy and Ricky discussing nuances of behavior, use with React Router](https://github.com/reactwg/async-react/discussions/5)
  • (22:53) - [The State of TanStack, Two Years of Full-Time OSS](https://tanstack.com/blog/tanstack-2-years)
  • (25:57) - [TanStack DB 0.5](https://tanstack.com/blog/tanstack-db-0.5-query-driven-sync)
  • (31:01) - [Tanner teasing a WIP TanStack Start RSC implementation](https://x.com/tannerlinsley/status/1983999424486633931)
  • (32:25) - State of the web ecosystem
  • (33:13) - [Cloudflare November outage postmortem](https://blog.cloudflare.com/18-november-2025-outage/)
  • (36:10) - ["What if people don't want to create things"](https://macwright.com/2025/10/21/what-if-they-dont-want-to.html)
  • (39:39) - [“When Everyone’s a Developer, How Do We Promote the Web Platform Over React?”](https://webtechnology.news/when-everyones-a-developer-how-do-we-promote-the-web-platform-over-react/)
  • (45:53) - Related, [“Dead Framework Theory”](https://aifoc.us/dead-framework-theory/) from last month
  • (48:12) - [Alex Russell’s latest stats on web devices and network budgets](https://infrequently.org/2025/11/performance-inequality-gap-2026/)
  • (51:48) - Npm attack, [Shai-Hulud round 2](https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting-zapier-ensdomains)
  • (52:06) - [Analysis of its evolution in code](https://www.aikido.dev/blog/bugs-in-shai-hulud-debugging-the-desert) from Sept
  • (55:23) - [Our plan for a more secure npm supply chain](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/) from September
  • (55:29) - [NPM update on token management changes](https://github.blog/changelog/2025-11-05-npm-security-update-classic-token-creation-disabled-and-granular-token-changes/)
  • (55:34) - ⚡ Lightning round ⚡
  • (55:38) - [TS 6.0 hopefully Feb 2026, 7.0 (native) soon after](https://bsky.app/profile/danr.bsky.social/post/3m5fz3vw2z22s) (more details in the [TypeScript.fm](https://share.transistor.fm/s/ad05eae6) podcast)
  • (56:03) - [Latest TC39 proposal updates](https://bsky.app/profile/robpalmer.bsky.social/post/3m62djhwj3k2i)
  • (56:32) - [Chrome (and other browsers) wants to remove XSLT from the web platform](https://groups.google.com/a/chromium.org/g/blink-dev/c/CxL4gYZeSJA/m/yNs4EsD5AQAJ?pli=1)
  • (57:14) - [“Your URL is Your State”](https://alfy.blog/2025/10/31/your-url-is-your-state.html), and [David K’s “Goodbye, useState” talk](https://gitnation.com/contents/goodbye-usestate)
  • (57:46) - [Aiden Bai’s “React Grab” util](https://www.react-grab.com/)
  • (58:39) - [Creating a custom Node module loader to import from Bittorrent](https://evanhahn.com/node-torrent-import/)
  • (59:22) - [Ryan Carniato’s stream on researching “async signals”](https://www.youtube.com/watch?v=ori9xZhvNlc)
  • (59:33) - [Details of building Node’s TS type stripping support](https://satanacchio.hashnode.dev/the-summer-i-shipped-type-stripping)
  • (59:58) - [The Web Animation Performance Tier List](https://motion.dev/blog/web-animation-performance-tier-list)
  • (01:00:14) - Conferences ([React](https://react.dev/community/conferences), [Javascript](https://confs.tech/javascript))
  • (01:00:22) - CFPs
  • (01:01:01) - [React Paris](https://docs.google.com/forms/d/e/1FAIpQLSfLICWs7vpK5fuMkZyJk4GyDtZBs08NMKJ0eIOOZBUxo98beQ/viewform) ([Also a community survey](https://docs.google.com/forms/d/e/1FAIpQLSd0pjOsMo0z3fvhv9EhgvUBWA4CdIcsivOCQi8wBmiNc_yXPQ/viewform))
  • (01:01:12) - [JSWorld](https://docs.google.com/forms/d/e/1FAIpQLSfv3GuXwsDyR42XsvJwfFsN4SKjy8WvKtqYp_nEK0yhzVNP1g/viewform) CFP closes Dec 31, notifies by Feb 1
  • (01:01:18) - Ending

Creators and Guests

Host
Mark Erikson
An engineer maintaining Redux and Redux Toolkit, working at Replay.io to make smarter AI chat bots and debuggers using time travel.
Producer
Carl Vitullo
Solopreneur just vibing, posts are probably bullshit. Community lead at Reactiflux, the largest chat community of React professionals.

What is This Month in React?

How busy professionals stay on top of the React ecosystem. We give you a 1 hour recap of the latest news and nuance in React's development and ecosystem, upcoming conferences, and open source releases. New episodes the first week of every month, with live recordings on the last Wednesday of every month in the Reactiflux stage.

Hosted Mark Erikson (Redux maintainer), Carl Vitullo (startup veteran), and Mo Khazali (head of mobile at Theodo). See something for us? Post to #tech-reads-and-news

2-vcarl: Hello.

Thank you for joining us for the
November edition of this month in React.

As we recap what's going on in the
React, react native and web ecosystems

We're coming to you live from
Reactive Flux, the place for

professional developers using React.

and I am Carl.

I'm a staff product developer and
freelance community leader here at

Reactive Flux, where I do community
programs like these events and build tools

to help keep the community operating.

1-acemarke: Hi, I am Mark.

My day job is working at replay and
doing various time travel debugging

and information architecture things.

Outside of that, I, I work on docs.

I complain about the React docs
and I collect links and I go

rewrite libraries like emer.

2-vcarl: mo unfortunately could not join.

He had a, fire drill happen.

Metaphorical fire drill happened at
work like an hour before we started,

but generally we have Mo who is
head of MO at Theto and is very

active , in the React native community.

Kind of sad that he had to skip
out this month because he just

did react Native London, and I
was hoping to hear how that went.

But yeah, let's get straight
into it with some new releases.

First off, we've got better off 1.4.

I actually use Better off now.

Woo.

I have been excited about it for a while
because I don't like authentication.

Libraries generally, like stuff
like Passport or what, you

know, even clerk or the SaaS
businesses, just like none of them.

I didn't like them very much, so, was
very pleased to see an open source

library that looked to cover many
of the bases that I want and can

confirm after using it that it does.

So I'm excited to see better off
1.4, which is the first release

since I believe July when it did 1.3.

A couple of quick highlights from it.

It's got stateless off, so you can
do sessions without a database just

by not giving it one, which is nice.

It's also got SCIM provisioning
for identities in multi-domain

scenarios, which is cool.

Also some other little details
like database joins and

custom state for OAuth flows.

But yeah, just auth is a shockingly deep
subject when you actually start dealing

with the nitty gritty weirdnesses of it.

And I have generally found most open
source projects trying to support

authentication to be, to leave
something to be desired and better

off leaves the least to be desired
of the projects I've tried, so.

Love it.

New version

1-acemarke: I have thus far managed
to stay away from dealing with

oath at all in my career, and I
would like to keep it that way.

2-vcarl: Yeah, that's not a bad call.

Since I haven't been able to avoid
it, I went a little bit deep on

it and I don't hate that either.

It's interesting.

It's fascinating actually.

I don't know.

One of the vague startup ideas in
the back of my brain is related

to authentication and identity
management, which could be cool.

I don't know, maybe I'll do
something with that eventually, I

want you to unveil your mag opus

1-acemarke: happily.

So I talked about this a bit last
time, but Redux Toolkit relies on

emer for immutable state updates.

It always has since day one.

And we've gotten various complaints over
the years that, you know, emer is kind of

slow, but we've always said that we prefer
the fact that it eliminates accidental

mutations, makes reducers easier to write.

Of course, we want Redux
Toolkit to be fast, but we

also want things to be correct.

End users do not have bugs.

So I'd done a little bit of perf
investigation into Imer like a year ago.

Saw that it had gotten slower, filed
an issue, it was kind of left there.

And at the start of September, I myself
dug in and started trying to see if

I could optimize I ER's performance.

And I spent well over a hundred
hours collectively across September

and October, deep diving into Immers
code base, comparing it to other

libraries understanding how it worked.

And trained to do a bunch of performance
optimizations and so ended up filing

a few different prs Imer 10.2, shipped
last month with some small tweaks, and

Michelle West Rate just merged a big
architectural change and released it as

Imer version 11 just a couple days ago.

And then I was able to put out RTK
two point 11, which picks that up.

So free performance wins
for Redux toolkit and nier.

2-vcarl: Heck yeah.

That was what was the average speed up?

1-acemarke: the current builds average
about 20 to 25% across all the different

benchmarks varying by scenario.

And then there's another outstanding
PR, which adds an optional array

methods override plugin, which
drastically speeds up array methods.

2-vcarl: Heck yeah.

That's awesome.

We love a core performance improvement
and I, I wanna shout out the ecosystem

performance, you know, I don't know,

1-acemarke: E 18 E folks are awesome.

They have been doing a ton of work to
clean up large dependency trees and slim

down packages and remove dependencies
across a wide variety of tools

2-vcarl: Yep.

a stat that I believe we'll talk
about later, I saw in general

ecosystem commentary yeah.

I guess in the NPM supply chain attack
that we'll talk about later, a a a

stat that came out of a blog post from
that was that the average JavaScript

project pulls in 683, I believe
in was it transitive dependencies?

Just like, yeah.

It's a lot.

So

when you've got that,

many dependencies, performance
of the ecosystem is challenging.

Yeah.

1-acemarke: that doesn't surprise me.

I know that React app the last I saw it
defaulted to about 1500 dependencies,

largely because of Webpac, et cetera.

Vet's obviously a lot fewer, but
still that's, that's not great,

just for a whole variety of reasons.

2-vcarl: I guess teaser for y'all.

Later towards the end of the episode
we're gonna talk about web ecosystem

and there's been some blog posts talking
about like AI and how it defaults to

building react instead of using the
web platform and, how do we promote

the web overreact, things like that.

Which I don't know, it just feels that
we just started bleeding into that

topic and so we will get much more
deeply into that later in the episode.

1-acemarke: Next release.

So, storybook 10 came out.

Few different big points there.

One of the biggest is that it's
now ESM only, they've removed

all the, the common JS artifacts.

So they've shrunk the install size
and they've also drastically shrunk

the dependency chains as well.

As well as some improvements
to things like the mocking and

some of the storybook formats.

And then one other release of note,
the remix folks are continuing to

work on , remix V three after the
initial demo and announcements.

And they're trying to build it,
as I understand it, with a lot

of smaller reusable packages.

And they just put out the first 0.1
alpha of their event interaction package,

which is providing an abstraction
for being able to compose events and

listeners and behaviors together.

Looks interesting.

I'm not gonna claim I understand
like exactly the benefits this comes,

but nice to see the progress there
and I suspect that a lot of folks

are gonna get some use outta this.

2-vcarl: Yeah, I'm reading the
syntax here and it looks like

a different way of adding event
listeners to dom nodes, which, sure.

I don't know.

There's weird quirks.

And certainly the remix team and, you
know, Michael Jackson and Ryan Florence

specifically have shown, have demonstrated
a great willingness to jump into.

What many people consider solved problems
to reexamine from first principles.

So I dunno, they, they've done that,
they've done that repeatedly with their

own solved problems of data loading
in routing the interaction between

data loading and routing I feel like
that's one of the bigger complaints

about React router is that they
keep reexamining that same question.

So, I don't know.

It's interesting that they do
have interesting things to say

when I've seen them reexamine,
quote unquote solved problems.

So, I'll, I'm curious.

This looks a little strange.

It looks pretty divorced from the
DOM structure, so if you just like on

input element and then add a bunch of
listeners for it, that's curious anyway.

Yeah.

O one release, we'll see
what they come out with.

Okay.

That's all the new releases we got so far.

Let's go into some main content.

First off we want to talk a bit about,
yeah, mark, you are on a, an ecosystem

panel at React Summit this month.

1-acemarke: So, Let's see.

Addie has money, was moderating.

We had Seth, Webster from the React
team, react Foundation shun person,

Amy Ner Nicholas Gallagher, and myself.

A lot of the discussion was.

Us asking Seth Webster questions
about, so this React Foundation thing,

like how is this actually gonna work?

What does this actually mean for the React
team and the project and the ecosystem?

there is a video for the panel.

It's not unlocked yet.

I have access to it because
I speak at GI Nation events.

But the video should unlock
within a couple weeks, I think.

a few different points that Seth made
during the panel itself, and then

I had a chance to have a follow-up
discussion with him afterwards.

And there's a few different very
interesting pieces of news about

how the foundation's going to
work and what their plans are.

he talked a bit about some
of the, the funding process.

So, you know, large companies pay, you
know, a good chunk of money to be members.

The, the existing board member
companies have already paid up

for like three to five years.

And it sounds like he'd actually been
working on putting the foundation

together for over four years.

Like this was a very long
term kind of a process.

And they're hoping to do a number
of different things with the money.

They want to, hire some
additional engineers.

And he even said some of
that would be spent on having

engineers triage the issues.

And if you've ever looked at the
React repo, you know, that's a thing

that they do not do very often.

So even something like that sounds good.

They want to hire some more people to work
on the actual docs and they're hoping to

give money out to communities in some way.

Don't know details on that,

2-vcarl: Tell me more.

1-acemarke: exactly.

Another data point.

So a lot of the plans have to
do with the development process

of re the React project itself.

And transparency around that.

Apparently they were even hoping to
launch the foundation like a year and

a half ago, and then they realized that
like our own in day-to-day development

processes aren't ready for that.

We need to dog food the processes
ourselves first so that we're more

ready when the foundation goes live.

And so some of that was you know,
actually having docs and plans as

new features are being developed or
treating things and kind of like a, you

know, TC 39 staged process approach.

But one of the biggest things that
Seth told me directly was that.

Up until now, the React team has had,
you know, their, like their weekly status

meetings, and those are purely internal.

First off it was just all the React
team working at Meta and then it

was, you know, meta plus Versal.

But those meetings have always been
internal, private, and non-visible.

And Seth said that they eventually want
to literally open up the weekly React team

planning meetings to the public even as
like a, like a Zoom call with no password.

And that eventually, like designated
community reps would even be able to

actively participate in those discussions.

So that's a radical change in
the development of React itself.

He also said that they're planning
to, resurrect or like completely

redo the RFC process, which frankly
was kind of dead from the beginning.

It was where random people from the
community posted ideas that got ignored

and the React team posted, finished.

things that they planned to ship and
then people argued over the naming

and the React team ignored that.

So like historically, the RFC
process was pretty much irrelevant

to actual React development.

Now they're talking about making it
like a real meaningful discussion

and part of the planning process.

Now, again, like do I know how
this is gonna work out in practice?

No.

But I can see the amount of effort and
the intent behind the foundation and

the plans that they're talking about.

And even if it doesn't end up going
exactly as they or we would hope, I

see good faith and good intentions
behind all the work that they're

trying to do around the process here.

So I'm actually very,
very excited about this.

2-vcarl: Yeah, that's interesting.

Oh got a lot of thoughts
rattling around my head.

'cause that's a lot of stuff that I've
looked at trying to contribute towards

the solution of but yeah, I don't know.

It's, I fundamentally, I feel like
the problem they're dealing with

is that a lot of people care about.

The outcome, the output, what
they make and what React is.

And not a lot of people actually have
like the context and the background

to like meaningfully contribute to the
advancement of that goal., you know,

to respond to what you just said about
like their motivations and their,

what they want to do, I don't think
that's ever really been the problem.

They've always had good intent and I
even think a pretty clear eye picture of

what the problems are, but I think the
problems are really thorny and complex

and the solutions to them are non-obvious.

And even when you have a good
solution idea, executing it in

a way that is effective and.

That operates on the, kind of like
timescales that React is around four.

It's just really challenging.

Like it's, you know, anyone can spin
up a process and run it twice and you

know, maybe that, like you do, you call
for comments and you run a community

discussion and round tables and whatever.

But like that plays out over the timescale
of like weeks and months and React

seems to plan on the order of years
and is now, has existed for a decade.

So, you know, with like there's
possibility for its scope to expand from

thinking in terms of years to thinking
in terms of, I don't wanna say decades,

but that's the next unit of time.

That's the next order of magnitude.

I hope they can achieve their goals.

I am looking forward to seeing
some more roadmap, transparency.

Of some sort actually.

That'll be really great for us, for
you and I. That'll would be great.

That'll be a great source of signal
that we can then pick apart and

analyze to surely, to much to their
chagrin by way of drawing attention

to things that are high context text.

1-acemarke: As opposed to like
stalking the open PRS list.

2-vcarl: Yeah.

Right.

Cool.

Nice.

Love that.

1-acemarke: So on that note Another
item that I've personally been

involved in is the work on the
upcoming React Concurrent Stores, API.

So when React 18 came out the React team
included the Uyc external store hook

as the official built-in way for third
party libraries like Redux, Zein, Jo Tai,

whatever else to integrate into React.

take an external state update, turn it
into a React re-render, and it worked.

But it also had a very intentional
design limitation that if you do an

update in the middle of a paused React
render, you know, something transition

like, then it bails out of that and just
does a complete top to bottom render.

So you're kind of throwing away
some of the benefits of React,

being able to pause itself.

And that was because they, they
really didn't have a better idea

for how to do that kind of interop.

So this concurrent store's API is
supposed to be essentially a new

equivalent to use sync external store,
but concurrent transition compatible.

And Jordan Eldridge, who's on the
relay team, has been working on

the design and initial prototype
IMP implementation for this.

And so he put out a polyfil package that.

Roughly implements the prototype
as a standalone library.

And then I've been talking with him
about, you know, here's what Redux

would probably need to make this work.

Here's our, our requirements for this.

And so I was able to then take his
proof of concept package and put

up a draft PR for React Redux that
just swapped out our use selector

implementation to use that instead.

And it basically worked, I mean, just
the one test file found a couple edge

cases, but like most of our tests
passed, we're not doing anything

transition related in our tests.

But it's good to know that like your
baseline standard behavior works.

And this also turned up several more
things we'll have to figure out, like.

Quality checks and how do you
handle selectors throwing errors?

And we're talking about when can react
safely, call selectors, can it delay it

due to batching and things like that.

So also very excited to see the
progress being made on this.

A PIA lot of people have asked
for external state transition

compatibility, and so this is going
to be a big deal for the ecosystem.

2-vcarl: Interesting.

Cool.

I'm just trying to put this in a
little bit of context for myself.

So this is a, an exploration of an API
for a concurrent store that they've

indicated intent to ship eventually.

1-acemarke: Mm-hmm.

Yeah.

so basically a, a new equivalent
of use syn external store, but

minus the sync restriction.

2-vcarl: Got it.

Okay, cool.

Interesting.

you called it a polyfill.

And I see in the blog post it's
labeled a pony fill, which I had to

refresh my memory on the distinction.

A polyfill fills in a gap in the
platform transparently, and a pony fill

offers the same functionality, but as a
standalone module that you have to import.

There you go.

Now you know.

1-acemarke: So one more item
kind of related to that.

At React Con Freaky Hanin announced
a new Async React working group to

provide support to the, you know, the
community and the ecosystem on, you

know, improving the React docs around
async behavior, helping libraries

get set up to use these methods.

And so Matt Brophy from the React Router
team had a good discussion with Ricky

about how they're trying to handle,
using transitions in React router.

So there was a, a good technical
discussion about the nuances of behavior.

And then the React router team also
put out a pre-release version or

unstable option to enable some of
the transition behavior as well.

So starting to see some adoption
and this ties into the React team

wanting to see libraries pick up
these behaviors like transitions and

action props and, and build them in.

I will say that I had a couple discussions
at JS Nation React Summit were some

people were questioning whether making
the entire ecosystem change semantics

and behaviors and add props to make
the React team happy was gonna be a

good idea or feasible, but we'll see.

2-vcarl: Yeah.

Interesting.

I see a bit of why they, why
the core team desires that.

Transitions are definitely like,
my understanding of the core

team's incentives and what they
care about is ability to use the

platform and things like that.

So given that like transitions are
a part of the platform and they are

interested in allowing people to take
advantage of platform improvements, I

understand why they would message, in
order to use this, the entire ecosystem

must make this change to the patterns
they use for compatibility reasons.

But that is very, I don't
know, that's a big challenge.

it's hurting a lot of cats
who don't necessarily.

Aren't even necessarily aware that
there's an attempt to herd being made.

1-acemarke: if you watch Ricky's
talk from React con, you know, he,

he demoed switching from like a bunch
of manual use effects and loading

states to suspense and transitions.

And then he pointed out, and so now
you have a much better experience,

but you also had to do, you know,
call start transition and all

your click handlers and so on.

, there's even some painful nuances there.

Because start transition
is based on setting a flag

internally for the current event.

Loop tick.

If you have a callback that has an await.

You leave the event loop tick, and
if you then want to do another state

update after the await, you have to call
start transition a second nested time.

And Ryan Cardo actually pointed out
to me that like Ricky has repeatedly

messed this up in his own demos.

It's a very foot gun
prone behavior pattern.

And so the combination of like you
currently have to call, start transition

yourself, plus trying to get the patterns
right is a good argument for let's

just build this into all the libraries.

But that takes time and
effort and coordination.

2-vcarl: Yeah.

Right.

Like that was one of my big takeaways from
Ricky's talk was, oh, this looks hard.

Which is not the best takeaway if
you're trying to convince the whole

ecosystem to move on to something.

1-acemarke: there is a
lot of complexity in.

Mental model of React and the kinds of
apps we're trying to build, and both

the fact that you now need to keep
track of additional API methods that

you have to call and the semantics
and when you're supposed to use them,

and the fact that your, your state is
now kind of in multiple Schrodinger

box, multiple versions at once.

It's, it's definitely a lot
of additional mental overhead.

2-vcarl: Yeah, right.

I'm just looking at in this GitHub
thread that you linked, Ricky

says, you know, oh, I think there
may have been some confusion.

Here's how you do it for navigations,
and it's, you know, function, navigate

to A URL that has start transition,
which, you know, wraps set router

state, which then wrap, you know,
it's argument is a function that.

I guess returns, A-A-U-R-L.

It's a thunk for set router
state in start transition.

In navigate.

I don't know, they're like,
that's just complicated.

Like what, why are we wrapping
this with so many different

functions just to navigate?

That's uncomfortable.

It feels like the wrong API in some
way, you know, like it an API should

obscure complexity and this does not
obscure the complexity so Interesting.

I, I want to be able to take
advantage of transitions in apps.

'cause that's super great if you
can just like, easily convey that

you are here and you're about to go
here instead of just going there.

Like, you get a lot of really powerful
things that you can do for user

experience and, you know, whatever,
all sorts of stuff if you communicate

the transition instead of just
updating the current state of your app.

But yeah, I don't, I,
I'm not sold on this.

I'm not sold on what I'm seeing so far.

1-acemarke: Okay.

Moving on to the.

Next related chunk of topic.

The Tans stack folks have a bunch
of updates that they've put out

both blog posts and versions.

So Tanner put out an article on the
State of Tans stack as an organization in

his own work as a full-time open source
maintainer for the last couple years.

Also, again heard, you know,
heard some of this from, from him

directly at react Summit loosely.

He himself has been full-time supported
open source for the last couple years

sponsorships to the TN stack org.

Hand stack libraries are, you know,
as we all know, very, very widely

adopted and Certainly query is the
standard fritz thing at this point.

Router and is picking up a lot, lot
of popularity start is almost 1.0.

And he's hoping to be able to start
to bring in some part-time or even

full-time people to hand stack
the company in the near future.

Essentially other current maintainers
for various hand stack libraries who

would then be able to potentially switch
to doing that as their actual job.

So essentially he's been fortunate
enough to have this workout for him and

he's hoping to share that ability with
other people working on the projects.

2-vcarl: I see says monthly
sponsorships for 12 core contributors

and short term contracts for
another three to five people.

I guess it's not clear what
monthly sponsorships means.

I, my assu, my assumption there
would be like their, maybe not full

time, but getting like sign, you
know, significant compensation, but

that may not necessarily be true.

1-acemarke: I don't know numbers, but
I think at the moment the others are

doing open source and they're full-time
and getting some, some stipends, and

in the next couple years he's looking
at actually hiring some of them.

2-vcarl: Cool.

Love that.

That's super hard.

Building revenue so that you can
actually support other humans

is actually really challenging.

I really like this blog post about,
you know, tan Stack for two years.

like this line.

You know, building a full
stack framework is hard.

I knew that from watching
other teams do it.

Most of them had something I didn't.

Capital Next Gatsby Redwood Remix all had
funding companies or acquisition paths.

And that, that definitely is something
that feels very different about Tan Stack.

It feels very much like
he couldn't not do this.

Like he just, has spent several years
working in this problem space and

solving his own problems with the
freedom to publish them so that other

people can take advantage of his work.

And then got to a point where it just made
sense to invest more effort and take those

a little bit further than they could go.

Absent that level of
dedication I, which I, I love.

That's just like, that's, I don't know,
finding that kind of work to do for

yourself is what I've been looking for.

And it's really hard to find,
and I love that Tanner Wesley

has apparently found it.

And also having 16 partners
doing sponsorships is also great.

Like that, that, that may not be
capital, but that's, that's great.

That's nice.

having tried to find sponsors myself,
like getting 16, it's like, oh shit.

Good job.

That's awesome.

1-acemarke: So it tens Stack DB is a new
work in progress package largely being

worked on by Kyle Matthews, formerly
of Gatsby, currently of electric SQL.

That is meant to be kind of
like a half a sync engine layer

on top of another data source.

And so like one of the common usage
patterns for that would be you

wrap it on top of your 10 stack
query, you know, API definitions.

And so maybe you've got
some endpoints for fetching,

post comments users, et cetera.

But then it presents like a sync engine
like interface on top of that, and

it's got a bunch of data flow analysis
baked in so that it can do things like

partial fetches or only re fetching,
you know, certain pieces of data.

joining.

Essentially presenting like a normalized
facade layer over the individual

endpoints so that they act like
they're unified almost as a, like a

replacement for a GraphQL style API.

And so they've been working on
this and it has integrations with

Tan Stack Query and then Electric
SQL and a few other data packages.

And Tanner pointed out to
me at React Limit that.

It really just needs an adapter layer to
be able to connect to another library and

I could totally build one for RTK query.

And so I was actually briefly
playing with that on the flight home.

Haven't had a chance to push it further,

but I'm actually, I'm actually very
excited to play with that more myself

because like 10 stack query, we made the
decision to make RTK query non normalized.

It just caches the
response from the server.

And so if this essentially let us
make a normalized layer on top of

our own library without us having
to make any further API changes.

That's very interesting to me.

2-vcarl: I'm also thinking about,
you know, this is from Kyle Matthews

who did Gatsby, which, you know,
notoriously exposed a GraphQL,

you know, layer on top of whatever
data sources you wanted to give it.

So just, I'm thinking about how
how much of Kyle Matthew's work

could be described as providing

query abstractions over
arbitrary data layers with data

1-acemarke: Yeah.

that's a good point.

I, I had, I hadn't even drawn that
connection that this is actually

very related to his prior work.

2-vcarl: if you describe this at a
certain level of abstraction, this

sounds just like GraphQL, relay Gatsby,
a bunch of other stuff, but I do see

the niche that it occupies and how
it's distinct from those projects.

it's kind of like GraphQL except
instead of the network boundary,

it's like the component to data
store boundary on your client app.

Which that's useful if you can, like
what you just said about how you

don't normalize in RTK query I've
landed on that as being generally a

good architectural decision to make
in applications because like if you

start doing data transformations.

You know, bespoke data transformations
per endpoint, then it becomes really

hard to change those endpoints.

If, if you're changing the underlying
data, then you've gotta change

all the code at the same time.

Whereas if you just take whatever
the API gives you and then write like

a transformer on top of that, then
it's just you, you add a layer of

abstraction for yourself that gives
you a little bit more flexibility

around timing of some types of changes.

So yeah, I dunno that's, it's interesting.

This is an interesting project.

I dunno, something about it feels like
I don't quite know where I would take

advantage of it for myself, but I could
see the right app with the right kind

of team operating it, finding this and
being like, this is exactly what we need.

This solves multiple challenging,
thorny problems that we have

or, so, yeah, I don't know.

It's interesting.

1-acemarke: my own personal to-do
list is massive at this point.

Both like redux and even just
like personal life stuff.

But I, I absolutely want to go back and,
and play with my own RTK query integration

prototype for that in the near future.

2-vcarl: Yeah.

I generally love the idea of sync engines.

one of my core beliefs about writing
code is that many more applications

that we use have no technical
necessity to be online only.

Like there are a lot of things like,
for example, my favorite canonical

example of this is like Gmail.

If you're using the Gmail app, it
doesn't actually care if you're online

because it is doing synchronization
of your emails in the background.

And so you can just interact with it
normally while you're fully offline

and later it will do all the things
like synchronize the read states or

like, you know, which emails you've
archived and deleted and yada, yada

yada, completely transparently.

Like, I have never thought about,
oh, I should wait to do this

later when I'm online, so I don't
cause weird problems for myself.

And I do think about that all the fucking
time in various other apps that I use.

So like there, that's something
that we used to do that we no

longer do because it's hard.

I love seeing more effort and
energy being expended into making

it easier to do offline things.

And sync engines are a big part of that.

And so abstractions over sync
engines are also a part of that.

Great.

1-acemarke: the Tans stack router
folks also put out a really good

blog post talking about how they did
some massive optimization on route

matching, including using a somewhat
lesser known data structure called

I think it's pronounced a try, TRIE.

I love, I, I love seeing
optimization breakdowns.

So good article there.

And then I. Since we've done plenty
of, you know, stuff being teased on

Twitter discussion in the past with
Remix and everything else Tanner has

been teasing that they are working
on RSC support for Tant Stack Start.

And I can say that he showed me a demo
and it's unconventional, it is not

what you would expect after having
used next, and yet it totally makes

sense in its own way once you see it.

So as I understand it, , they've made
real progress on implementing it.

, they figured out the design
and now it's push it forward

and make it actually a thing.

I have no idea how soon this will be
revealed, but I think once this comes out,

it will be a very interesting, challenging
take on our understanding of server

components and how they, how to use them.

2-vcarl: I would certainly say
that the way next has done it does

not seem to be like the end all,
be all of great implementation.

So if they have found a new
way to approach it, hell yeah.

Here for it.

That's awesome.

1-acemarke: So there, there's
your, vague tweet for the month.

2-vcarl: Yeah.

Right.

let's talk a little more broadly.

Let's talk about the state
of the web ecosystem.

I guess like to intro our subtopics
under state of the web ecosystem.

I wanna talk a bit about
like the CloudFlare outage,

the NPM ongoing attacks.

Like this is not a new attack, this
is the, a continuation of the previous

attacks plural, that we've discussed.

As well as, Alex Russell had a decent
blog post, I say decent because I

don't know, it's, it qualified, decent.

It, it's well written, it's well
argued, but I don't necessarily

agree with his conclusions.

And also there, there's some
conversation about reacts place in the

ecosystem and AI and things like that.

So that's the shape of this state of
the web ecosystem chat that I want to

start or that I want to have, I guess.

Yeah, let's start at CloudFlare.

They had an outage on the, earlier this
month, about a week ago 18th of November.

They say in their outage postmortem
that it was triggered by a change to

the permission system of one of the
databases, which caused it to output

entries ba Basically, it produced two
large of a file that then got distributed

out and the size of that larger file
getting distributed, caused performance

load that took down the network,

1-acemarke: check me on this,
another factor on it was they,

one of the services was written
in Rust and it had an expectation

that the file would only be so big.

And there was, I think there was
a rust line of code that basically

said if it doesn't fit, panic.

Yeah, that when a bad file with like
, they had 60 features, a limit of 200

and a line of code that basically
said if it gets over 200, throw

throw an error, kill the service.

2-vcarl: That'll do it.

Yeah.

Each module ran on the proxy
service has a number of limits to

avoid unbounded memory consumption.

somewhat questioned the wisdom of that
because, the reason you would have

limits on memory consumption in place
would be to avoid outage and downtime.

And so if your resolution to, the outcome
of your limit, if memory usage gets too

high, is to crash, that is functionally.

Very similar to an out of memory error.

Maybe it's, I guess it's easier
to debug, I guess you can, out

of memory errors cause Crazy,
unpredictable failures, I guess.

So at least this is a predictable failure
that strongly indicates where the , the

excessive memory use is coming from.

But yeah, it it was pretty serious.

I actually didn't notice,
which I'm glad about.

It's nice to not be so online
that you don't immediately notice

every, I don't know every outage.

But yeah, you know, as people are
discussing how React takes over,

you know, is now the default for web
development, this kind of, I think this

was a, a a good demonstration of the
place in the ecosystem that CloudFlare

occupies and how many different services
truly rely on its stable operations.

Yeah.

1-acemarke: Trying to make the trade-offs
between, the web is decentralized.

Anyone can run their own thing
versus, Hey, look, , there's

benefits to having centralization.

Let's all put our GitHub, or let's, let's
all put our git repositories on the same

service so we can, you know, log in and
share them and comment back and forth.

Let's put all our

social media comments on the same service.

We can have commentary back and forth.

Let's all use this widely spread CDN and
DDoS protection service that also has a

bunch of really cool backend services.

And then when one of those big services
goes down, it ends up having, or everybody

put everything in A-W-A-W-S East one.

2-vcarl: Yeah.

right.

1-acemarke: Or, or, or even like
we, we put it in AWS East two,

but AWS themselves relied on AWS
East one and then it goes down.

we keep running into these big
dependencies that end up having massive

effects on the internet when they go down.

2-vcarl: This feels like a good
transition point to a link that

we had slightly later down.

Tom McRight, who is not a name
I recognize, put on a blog

post called What If People
Don't Want To Create Things and.

that feels like what you're talking about.

Like the ideals of the web
is decentralized, you know,

1-acemarke: their own domain.

2-vcarl: right?

Sharing knowledge, sharing skills,
sharing tools, and I love that.

I agree with that.

I aspire to those ideals.

But it's also true that like, we
kind of just want stuff to work.

we want it to just kind of be stable
and, you know, it's not stable,

decentralized things that have a
smattering of volunteers maintaining it.

That's kind of the distinction.

Like that's kind of the trade off is
like over time decentralized things

with enthusiastic maintainers and,
open source over time that stabilizes

and grows and becomes great in a way
that proprietary code can't, because,

you know, you can't inspect it.

You can't say like, I'm
encountering this bug.

Let me go look at the code.

Oh, here's where it's coming from.

Let me tell them about it and give them
a reproduction and contribute to a fix.

Like, if I encounter a problem like
that in, any of these many proprietary

tools that I use, then there's
just no path for me to do that.

So, but on the other hand, they
have the capital and the employees

to have people proactively looking
for that, where it's their job.

that's the tension.

I tend to believe over a long
enough time scale that distributed,

decentralized things like the web
will be better than anything that's

like proprietary developed, but.

It has to work well enough
to get the attention.

And you know, in this attention economy
we're in, it's very hard to get people who

have enough bandwidth of their attention
to say, I have found this problem.

Let me chase it down to its
logical conclusion and contribute

to a fix being actually shipped
for me and people like me.

1-acemarke: aren't gonna go off
on this, but I could even see some

tangential connections with things
like open source as a concept,

open source maintainer, burnout.

Like most people, like using an app or
a library or even even developers using

a library, like in the end, do they
actually care that it's open source?

No, they just want to download the thing
and have it work, whether it's Libre

office or you know, a paint, you know,
paint program or better off or whatever.

And the fact that the
code's open doesn't matter.

It's like I, as the consumer of this
thing at this level just want it to work.

And if it doesn't, I ask the person
who builds it, just make it work.

2-vcarl: Right, I'll call out
a couple of quotes from here.

Beautiful data, visualizations are
free to make, but the supply of people

who really love and know D three is a
lot lower than I expected it would be.

I love home-cooked apps and
malleable software, but I have

a gnawing feeling that I'm in a
bubble when I think about them.

Most people's lives are split into
the things that they affect and create

and the things that already exist
and wanna tune out and automate.

I think that's a, I
think that's insightful.

I think that speaks to a deep,
I don't know, tension in this.

Like, yes, AI lets you do a much
larger range in a much shorter

time span than used to be feasible.

But do people want to do that?

I don't know.

Given the, given a range of infinite
possibilities, how do you pick

which one that you are going to do
and then give it the attention so

that it actually produces something
that other people can benefit from?

How do you find the things that you
want to build on top of, you know.

Well, I guess I'll transition from that,
from that comment to this other post.

When everyone's a developer, how do
we promote the web platform overreact?

It's in reference to this Alex Russell
Post that I'll, I'll, I'll share after.

But I guess it's talking about, it's
talking about that like when people

can make their own software, when
they can just use plain English to

ask AI to generate code that in one
form or another, solves the problem.

They stated, you know, maybe not
the way they intended, maybe not

the way they wanted, but it, it's
doing its best just like all of us.

It's talking about how if you just
ask it to make something, it's

probably gonna use React, because
that's what, by volume of text, by

volume of code that it's trained on.

That's what.

That's the mode, that's
the most common example.

I guess like this is
framed as a, an AI problem.

Like why does AI do this?

But this is actually the same problem
that I've observed well before AI

came out, you know, 2022 or when
everyone chat GPT really started.

I have observed all of these
problems that it's talking about

over the life of my career.

Like, you know, especially I
feel like, you know, there's a

certain golden age of tech between
2018 and, I dunno, 2021 or so.

And that was absolutely the case.

Like I would, you know, join a new
workplace because I did that a lot.

I worked at a lot of different
companies and I'd look at the

practices people were using.

It's like, why did you use React for this?

Like there's, here's a platform
feature that solves this more easily.

And with less code.

And a lot of the time people
just didn't know it existed.

Like it's that attention problem.

How do you know what you
should build on top of?

don't know.

It's, the solutions here that people are
talking about is like, what can we, the

web community do to promote web platform
features overreact code and it proposes

teach vibe coders to explicitly prompt
for web native solutions get the LLMs to

ingest more web platform code, spotlight
teams and projects that ship modern web

experiences without heavy frameworks.

I mean, like, that's, to me all of
those, essentially just like how do

you make the web platform more popular?

to me, AI fundamentally
spits out an average.

It spits out like you ask it to do
something and it will give you a deeply

profoundly average result for, you
know, if you ask a thousand people,

that question here is approximately
what the mass of those people would say.

And it's true that if you asked a
thousand developers to do something

on the web, the most common output
would probably be a kind of shitty

implementation with React that overused
things like use state news effect because

that's what developers did and do.

So, I don't know, it's like a lot
of these questions that we ask

ourselves about AI and code, I feel
like distill down to the same kinds

of questions we were asking before.

But like now, there's a boogeyman of ai.

Like this is ai, this is this, this is
code, this is a product people have built.

And so it is now a very convenient
boogeyman, but it, it's a distillation of

the thoughts of a vast number of people
as codified by what they published and

what was ingested for the training set.

1-acemarke: I just tossed in a link to
the obligatory XKCD from like a decade

ago, which is the, the one of the points
out that sometimes your, your map or

your heat map of users is actually
just a heat map of the population.

It's a one-to-one correspondence.

2-vcarl: Yeah.

1-acemarke: So I think that that is
partly what we see with like react usage.

You know, there, there's a
lot of people who use React.

There's a lot of people who use React
badly and therefore like, the spread of

types of usage of React, the quality of
usage of React kind of maps to the quality

of programmer skills and backgrounds.

Like, not necessarily an excuse.

And that's not to say that like
everything about using React is, is

good by itself, but just that when
you have a full cross spectrum of the

population using a thing, you're going
to have the full cross spectrum of the

population using it in good and bad ways.

And so in the same way when it like.

, when it comes to, you know, people
building apps, re React got popular.

Where LLMs came out and saw
that was re react was popular.

So LLMs repeat what
they were trained to do.

And plus it's also, you know, like
not just popular, but it's especially

popular within Silicon Valley,
within all the companies making

the AI builder tools, et cetera.

So in a lot of cases, they're
prompting them to just use React

because they assume it's the
default that you would use anyway.

2-vcarl: I wanna shout out a term that I
love path dependence, which is like, where

you're at right now is the outcome of a
series of choices that were made in the

past, and those past choices constrain
what paths are available moving forward.

That's path dependence, where you came
from, effects where you can go and.

So I guess like to me that
this is a complaint about

the path dependence of React.

Like, because React got popular now
React is, , we've worn that rut and so

now it's hard to get out of that rut,
even if there is a better alternative.

And so I would say like the solution
there isn't like, I don't know,

tell people they're bad at things.

The solution is to like make better
resources so that a different path

becomes the easiest one to take.

And mass, you know, writ large when you
know, it's, one thing to convince 15

people that this is the best solution
and it's correct and it's another to make

the argument clearly enough, strongly
enough, and consistently enough over a

long enough span of time that it affects
the behavior of millions of people.

So.

You know, how do we promote the web
platform overreact, like do a better

job promoting the web platform?

'cause there are, thousands of
people who are writing resources

for React because that's where
money and attention and time is.

So if you want to do better than that, you
have to make a resource that is better.

I don't know that.

There you go.

1-acemarke: Yeah.

Yeah.

So the, the, the other, there was
a related article from last month

entitled Dead Framework Theory, which
was specifically addressing like

the, the LLM training data aspect of
this and how it, how it becomes a,

sort of a self perpetuating cycle.

And also pointing out that like if you
have a, a new library or a new tool or

a new web platform feature that is just
now baseline, newly available, there's

a lag in common LLMs knowing about that.

So it's sort of like that,
defaults win kind of an issue.

2-vcarl: Yeah, and I'll say, yes, defaults
win, but That doesn't mean that it's

impossible for an, you know, to, to
approach the problem in a way to mitigate

that kind of, you know, home field
advantage that tools like React have.

I've shouted out a number of times in
a bunch of different contexts because

they do a good job, but I love effect,
one of the things they do really

well is documentation, and one of the
things they do really well in their

documentation is making it legible for ai.

I recently over the summer built
a Greenfield project with Effect,

and I did it extensively with ai.

, a mixture of having it right and then
having it educate me and then rewriting

it and then having AI rewrite what I
did, you know, just get there over time.

But I was able to do that despite it being
a new library that's even at odds with the

kind of patterns that AI wants to write.

It's a functional type, it's a
functional programming typed standard

library essentially, which is not
at all what AI wants to write.

AI wants to write object oriented classes.

And despite that, I was able to
make it, figure it out and learn it

and do a good job, good enough job
that I got something I was proud of.

You know, not just vibe coded.

I was proud of it.

I told people in my life, this is the
best code base I've ever worked on.

And it's a large part of that
was because of how they affect.

As a, you know, organization and
library approach, their style

of documentation, they made it
legible for these automated tools.

So I guess like if you wanna promote
the web platform over incumbents,

like react, then like figure out how
people are writing code, figure out

how people are consuming documentation,
consuming new knowledge do a good job.

1-acemarke: I'll note though, that you,
you are the one who decided you were

going to use effect and told the LOM
this is what I'm going to build with.

2-vcarl: It's true.

Yeah.

1-acemarke: the last wink on this
particular topic Alex Russell who used

to be at Google now has been, Microsoft
has been very vocally beating the drum

that most client side js is bad, that JS
bundles keep growing, that most people

are using, you know, older Android
devices on mobile with very weak CPUs, and

therefore Js load times are worse versus,
you know, developers using an iPhone or,

or a Power or a Fast Mac or something.

And he just put up the latest article in
his ongoing series you know, documenting,

sta like average bundle sizes, average
network speeds, average CPU uses.

I have a lot of respect for him
Technically his stats are correct.

His points are right.

I have questions about his delivery and
tone in how he accuses people of doing

the wrong thing, but it's also very true
that a lot of people should be paying

more attention to him and actually
trying to shrink down bundles instead.

2-vcarl: That's interesting.

I a thought I've had, I haven't
validated this thought against, you know,

ground truth, but been hearing about.

Bundle size as a problem.

Essentially what he's talking about
here, like we ship too much JavaScript

for the compute capabilities of
commonly used devices like that as a

thesis has been something I've been
hearing about for a very long time.

Much of my career even, and I'm not
sure that the bundle size problem

has gotten that much worse over
the last, I'll say eight years,

you know, call it, since 2017.

And he shows a chart of compute speeds and
basically shows like, yes, top of the line

devices have gotten five times faster,
low end devices that 75% of the world

uses have not gotten measurably faster.

And that's true.

Can't argue it.

His stats are correct, like he said.

But also like, I'm not sure the
problem is getting measurably worse.

The optimizations of how we can
split code and, you know, what the

JIT and the execution environment is
doing to make it work more quickly.

Those have gotten better over time.

And it's also true that like, so if
he's looking at the, basically like

every processor, anyone with a device
is using, and that is the correct stat

to consult if you are building something
that everyone in the world will access.

But that's not true for most startups.

Like if you're building a startup
that targets like some industry,

that American businesses.

Is target's a problem that American
businesses need solved, then like it

doesn't really matter what the MO mobile
performance in, you know, different PO

outside of that target industry, I guess
are, then it's like, like what you said

about his like tone and delivery, I think
a, to me when I read this, a core part

of what that I think he's overlooking
is that not everyone is trying to ship

something that 100% of the people in the
world can access smoothly and quickly.

Like, and that's fine.

Like, you know, not everything needs
to target everybody in the world.

So, I don't know, I, I guess
that that's one of my takeaways.

That's one thing that I
think is missing from this.

Otherwise, very technically
complete blog post,

1-acemarke: I think it's also true that an
awful lot of app teams out there ought to

be spending time thinking about even just
basic bundle sized stuff, and they aren't

2-vcarl: I do wanna talk about
the NPM hack that is ongoing

shy haud, the sand worm.

I want to call out as far as I
know, I keto.dev has been like

the security researchers who have.

Announced this, like uncovered it
and then analyzed it and shared it.

They had a really good analysis of
the evolution of the code, of the

attack of this worm from September.

And I, noted in that when I was
rereading it after this, you know,

new, new attack they had shouted
out that it appeared that they still

had more credentials in reserve.

Like they had cracked more credentials
than they had actually used.

And sure enough, this, you know,
round two attack in their analysis

of of it this time around, they note
that it was timed just before MP's

deadline for revoking old tokens.

So like very clearly they had a lot
of tokens that they had compromised

previously that they were now taking
advantage of before they, before

they lost access to it, before
those tokens were no longer valid.

And I guess to reiterate, we've talked
about, we talked about this attack before.

I would say this is, this represents
the current cutting edge of malware.

It is using all sorts of fascinating root
execution, like privilege escalation.

I saw discussion of it, starting a docker
container, mounting your file system

to that privileged environment and now
suddenly it has privileged access to

all sorts of files that it couldn't have
if it was just running in your shell.

Stuff like that, that's
pretty fascinating.

And other things, like if you have
a claw installed, it will prompt

Claude to say, Hey, look around
this file system for secrets.

Like that is very cutting
edge malware to me.

It's it's not just writing its own code.

It's not just a worm that is
trawling your file system.

It is taking advantage of other tools
that you take advantage of to attack you.

So that's, yeah, that's not great.

1-acemarke: I mean like
big picture, it's almost.

It's almost surprising how many widespread
pieces of malware have been very dumb

and weren't as nearly destructive
or smart as they could have been.

And like think of how much damage we've
had collectively as an industry over years

with only a lot of those dumb malware.

And now we're starting to see some
people write more intelligent malware.

2-vcarl: Yep.

Yeah.

'cause a month ago, two months
ago, whenever it was, there was

a different NPM hack that managed
to get into the debug package,

which is massively widely used.

And I assumed that it was the same
attackers as this attack because it's,

it it resembled it in a couple of ways.

Except that it was dumb.

It was so poorly executed.

Like they got close to unprecedented
access to the NPM ecosystem.

Like this is one of the first times
that, that previous attack, the debug

attack, was one of the first times that
I saw, here's this compromised version.

Let me check my file system.

Oh, yep.

There it is.

I've got this.

So yeah, they just straight
up fumbled the bag there.

my theory here, having paid attention
to this, it seems like there's some.

Hacker group that may have compromised
set up a, a phishing tool set, you

know, set up tools for other malicious
actors to run phishing attacks.

And it feels like two different hacker
groups took advantage of those tools

to target NPM maintainers, and only
one of them is actually technically

competent enough to take full
advantage of the access that they got.

So, yeah.

I believe we've shared
these resources before.

And GitHub put out our plan for
a more secure NPM supply chain.

So they're still working on that.

Clearly.

They also just released an NPM
security update earlier this

month in November, November 5th.

Mark, you want to just read through
any of these lightning rounds

that you wanna call attention to

1-acemarke: okay.

TS six and TS seven are hopefully
gonna be coming out early next year.

TS six is still the current
TypeScript code base, but with some

changes to defaults and deprecation.

And then TS seven would be
the native implementation in

go that they're working on.

So a couple different updates
on , the release plans there.

That's going to be very, very exciting.

I am excited to have TypeScript
compiler 10 times faster.

Also there were some more the latest
TC 39 proposals meeting as usual

advanced a number of different
proposals to different stages.

A couple of things that look interesting.

There's a promise dot all keyed,
which is essentially promise

dot all but for an object.

And then I am excited, irrationally
excited about object, keys length, which

is literally just to get the size of
the number of keys in an object instead

of object keys, parentheses, length.

2-vcarl: Chrome and a
couple of other browsers.

Want to remove XSLT from the web platform.

XSLT is a what domain specific
library for transforming X and

1-acemarke: transformations
within a browser.

So you, you send out an XML document from
the server and then you have a purely

client side declarative transformation
that like converts it into HTML.

2-vcarl: It exists.

I had no idea that it
was a browser feature.

I've known of it as a tool that
exists, but I had no idea it

was baked into the browser.

And they're looking to remove
it and I'm okay with that.

But certain people who I
guess use it for one thing or

another have been running a
campaign to say, no, please don't.

What about RSS feeds?

But yeah.

1-acemarke: Going along a bit with
the whole use the platform thing.

more people should be putting
some of their state in the URL

and there was a very good article
on using the URL as state.

And then along with that, another,
video from recent React Summit that's

probably paywall at the moment, but
I think he's done a couple previous

versions of this at different conferences.

David Korshe has a talk on goodbye use
state, similar to his goodbye use effect.

It's hilarious.

It's funny, and it also points
out why you shouldn't be using

actual used state all that much.

2-vcarl: Aiden by who did
Millions js put out an interesting

new tool called React Grab.

Basically letting you, you know, you,
is trying to solve the problem of

when you tell AI like, Hey, make this
thing different, and then it goes.

I don't know where that is.

here's your browser, but I don't
know where that is in the code base.

And so this is a tool that helps map.

similar to how you can use dev tools
to highlight an element this is

taking that kind of behavior where you
highlight an element in your browser

and it connects back to the actual
source code that produced that element.

As a means of giving AI a head
start on finding what code to

use which seems super cool.

I question the wisdom of the recommended
get started thing, which is just

to add a script tag to Unpackage.

I don't know.

Seems, seems slightly sketch, but also for
also seems really easy to to get started.

1-acemarke: One thing that caught my
eye in terms of like, this is awesome

and you should never, ever do this.

Was implementing a node module
loader that imports from BitTorrent.

okay, great.

That's possible, apparently.

2-vcarl: Love that.

I do love BitTorrent.

You know, as we were talking about

decentralized technology a little bit
earlier, like, man, what a, highly

resilient, decentralized technology.

But yeah, well, hey, you know, maybe if
we're gonna, if we're gonna encourage

people to do decentralized technology
building on the shoulders of giants

like it, man, if you want it to
like, never stop working, ever Sure.

Import your code from BitTorrent,
probably, it's not gonna work very

quickly, but given the right underlying
cedars that would, that may never go down.

Pretty interesting.

1-acemarke: Earlier I mentioned Ryan Cardo
streaming and talking about async signals.

Here's the six hour livestream video
if you want to watch that and or

throw it into a summarizer somewhere.

2-vcarl: I'll shout out the details
of building nodes the node type

script type stripping support.

Just 'cause I, man, I do love a
technical writeup and that is,

that was a massive feature release.

Just like the ability to use node
to run TypeScript code without doing

a compilation step was pretty cool.

And so here to here to signal boost.

A post from the author of it.

1-acemarke: And one more.

Since we spent much time talking
about the, the web platform the author

of the Motion Animation Framework
put up a really good post comparing

all the different ways you can do
animations on the web and talking about

some of the performance trade-offs.

2-vcarl: Super good.

Cool into some conference news.

We don't really have much
'cause it's the end of

the year and all of the upcoming
conference things don't show

anything for like January or February

1-acemarke: well, we don't have much
of a list here, but I can say that

I've actually been doing my own,
trying to prepare CFPs for next year,

and it ended up making a database
of conferences and like my own

personal list is like dozens of them.

And I can tell you there several
conferences have submission

deadlines like by November 30th.

Suffice would say there's a lot
more conferences out there that

knew existed until I spent several
evenings researching them and trying

to put this database together.

2-vcarl: I've tried to do that
consistently over the past three

years for this podcast and holy
shit, there are so many conferences.

It is absolutely bananas.

Some of them are even
fraudulent, so it's like you,

you actually gotta reschool them.

So, yeah, it's a lot.

But okay.

All that to say I am aware of React.

Paris has a CFP currently
open that's gonna be in March.

So if you're looking to talk,
then they've got a CFP open.

You can do that.

JS World also likewise has a CFP
that closes at the end of December.

Thank you everyone who has managed
to stick around for this, you know,

hour and 15 minute recording session.

1-acemarke: Funny, we said we didn't have
a lot of main content for today and go

figure, we had a lot to say about stuff.

2-vcarl: yeah.

Right.

I give us a, give us a blank
slate and we will fill it.

howdy.

joining us.

1-acemarke: the discussion
has been useful.

2-vcarl: that is my hope
I, if not useful, at least.

Interesting.

Cool.

Thank you for joining us.

We normally, I say we'll be back on the
last Wednesday of the month, but the

last Wednesday of next month I think is,

1-acemarke: December 31st,

2-vcarl: So I don't know, we're probably
not gonna do it on the last Wednesday

of next month, but we'll be back

1-acemarke: somewhere about
that timeframe, approximately.

2-vcarl: ish before the end of this year.

Yeah.

And then we'll, we'll be back in your
podcast feed just as soon as we can.

In general generally, I say we gather
sources from all sorts of news feeds

and whatever, but mark, you've done
a good job of being my source lately.

So mostly we get news from tech news and
reads, or at least that's where I get it.

I don't know where Mark gets it.

1-acemarke: all of the above
newsletters, plus like Hacker

News and Twitter and all the other
social media feeds, I obsess over.

2-vcarl: But yeah, we do subscribe
to this week in React Bite that

Dev React status next JS weekly.

Mark and I are both
subreddit mods of React js.

But yeah, if you see anything that
seems useful that you might want us to

discuss drop it in the Tech News and
Reads channel I'll at least read it.

I may not

bring it in, but yeah.

if this is a show that you get value
from and wanna support best way to

do so is by telling people about
it and submitting a review that'll

help us get discovered and whatever.

Cheers.

Thanks so much.

1-acemarke: Happy Thanksgiving.

2-vcarl: Yes, happy Thanksgiving.