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.