WEBVTT

00:00:00.000 --> 00:00:00.660
Carl: Hello everyone.

00:00:00.660 --> 00:00:04.200
Thank you for joining us for the
October edition of This Month in React.

00:00:04.500 --> 00:00:08.640
As we recap what's going on with React,
React native in the web, we're coming

00:00:08.640 --> 00:00:12.486
to you live from React Flux, the place
for professional developers using React.

00:00:12.989 --> 00:00:13.799
I'm Carl.

00:00:13.829 --> 00:00:17.970
I'm a staff staff product developer and
freelance community leader here at React

00:00:17.970 --> 00:00:20.939
Flux, where I run community programs
like these events and build tools to

00:00:20.939 --> 00:00:22.530
help keep the community operating.

00:00:23.009 --> 00:00:23.820
Mark: Hi, I'm Mark.

00:00:23.820 --> 00:00:27.299
My day job is at Replay.io and in
my copious amounts of spare time,

00:00:27.299 --> 00:00:29.609
I maintain Redux and rewrite Immer.

00:00:30.029 --> 00:00:32.399
Mo: I am Mo, I head the
mobile team at Theo.

00:00:32.700 --> 00:00:35.849
I'm an active part of the React
native ecosystem and community,

00:00:36.090 --> 00:00:39.479
and I organize the React Native
London Meetups and conference,

00:00:39.810 --> 00:00:42.026
which is coming up in two weeks.

00:00:42.170 --> 00:00:43.040
Terrifyingly so.

00:00:43.550 --> 00:00:44.030
Carl: Coming right up.

00:00:44.030 --> 00:00:44.240
Yeah.

00:00:44.240 --> 00:00:45.800
And you got a shout out
that we're gonna talk about.

00:00:46.160 --> 00:00:47.300
Let's start with some new releases.

00:00:47.300 --> 00:00:48.740
Mark, tell us about Immer.

00:00:49.325 --> 00:00:51.005
Mark: Okay, I can, I can
do both these things.

00:00:51.005 --> 00:00:53.285
So I actually take very
full credit for this one.

00:00:53.315 --> 00:00:58.595
So to be clear, I do not maintain the
Immer immutable update library that is

00:00:58.595 --> 00:01:01.685
Michelle West Rate, who created it and
has maintained it all the easier years.

00:01:01.955 --> 00:01:06.245
However, since the start of September,
I have sunk a stupid amount of time,

00:01:06.275 --> 00:01:11.315
something like 120 plus hours into
trying to rewrite the internals of

00:01:11.345 --> 00:01:16.475
Immer for faster performance after
some re users filed complaints to the

00:01:16.475 --> 00:01:18.425
Redux repos, that it was kind of slow.

00:01:18.935 --> 00:01:22.565
So I filed a few different prs,
one to make some relatively

00:01:22.565 --> 00:01:25.985
small tweaks, and then a couple
larger architectural changes.

00:01:26.060 --> 00:01:31.235
And Michelle just merged and released
Immer 10.2 with the small options.

00:01:31.475 --> 00:01:36.005
And we are hoping to land the larger
architectural changes in the near future.

00:01:36.305 --> 00:01:40.025
And those will probably come out
as Immer version 11, hopefully in

00:01:40.025 --> 00:01:41.555
the next few weeks or something.

00:01:41.884 --> 00:01:45.095
So I'm excited faster for
performance free upgrades.

00:01:45.155 --> 00:01:45.759
Yeah, should be.

00:01:46.550 --> 00:01:50.960
Carl: Yeah, love some big core
performance improvements of deep packages.

00:01:50.960 --> 00:01:51.440
That's awesome.

00:01:51.860 --> 00:01:53.990
Mark: And I will also hopefully
turn this into a conference talk.

00:01:54.559 --> 00:01:55.039
Nice.

00:01:55.460 --> 00:01:58.880
Along with that, I, I just saw the
announcement, I think like yesterday,

00:01:59.059 --> 00:02:03.570
that the author of the ARC type
validation Library, which is a, a

00:02:03.570 --> 00:02:08.630
competitor to Zod that takes a, a rather
different API approach, just released

00:02:08.734 --> 00:02:11.810
a, a similar tool called ARC RegX.

00:02:12.200 --> 00:02:17.030
It's a function that is supposed to
be a replacement for defining regular

00:02:17.030 --> 00:02:23.930
expressions in JavaScript, but it
actually parses the RegX string into

00:02:23.959 --> 00:02:26.750
TypeScript types so that it can both.

00:02:27.244 --> 00:02:30.994
Interpret at the type level, what
the regular expression is doing,

00:02:31.385 --> 00:02:38.285
and also even provide syntax errors
if the reg itself is invalid.

00:02:38.644 --> 00:02:40.625
Just looking at the
docs, my mind is blown.

00:02:41.165 --> 00:02:44.105
Carl: Well, yeah, other than
new releases, we have a bunch

00:02:44.105 --> 00:02:45.334
of main content this month.

00:02:45.334 --> 00:02:49.531
The React conf happened, what,
three weeks ago, and a bunch

00:02:49.531 --> 00:02:50.671
of new stuff came out of there.

00:02:50.761 --> 00:02:55.681
They did put up an official recap
blog post from it on the 16th, about

00:02:55.681 --> 00:02:57.571
a week after the event happened.

00:02:57.931 --> 00:03:01.141
The big takeaway here, I think, well,
I don't know, we got a couple of big

00:03:01.141 --> 00:03:05.731
takeaways, but one of the headlines
is definitely the React Foundation.

00:03:06.211 --> 00:03:09.811
This is a pretty big change to, or this
sounds like it will be a moderately

00:03:09.811 --> 00:03:12.541
large change to the governance of React.

00:03:12.901 --> 00:03:16.681
They're pretty light on details
of the actual governance, so far.

00:03:16.741 --> 00:03:19.921
They have talked about like a
new technical steering committee.

00:03:20.351 --> 00:03:24.011
But they also say that the
governance of that is not finalized.

00:03:24.011 --> 00:03:28.751
The members are not finalized, but
they do have the founding members of

00:03:28.811 --> 00:03:33.881
the founding sponsors basically of
this foundation, which are Amazon Call

00:03:33.881 --> 00:03:39.401
Stack, Expo, Meta, Microsoft Software
Mansion, and Vercel with Seth Webster.

00:03:39.551 --> 00:03:42.581
Seth Webster is executive
director and he's the what

00:03:42.581 --> 00:03:44.051
manager of the React core team,

00:03:44.741 --> 00:03:45.281
Mark: Basically.

00:03:45.281 --> 00:03:45.641
Yes.

00:03:46.061 --> 00:03:47.801
Carl: Yeah, so that makes sense.

00:03:47.801 --> 00:03:52.301
He is basically already doing that
role and expanding what the core team

00:03:52.331 --> 00:03:55.841
means to an intercompany organization.

00:03:55.961 --> 00:03:59.111
But yeah, it's a lot of the details
that I was most curious about, like what

00:03:59.111 --> 00:04:01.786
does, what does this mean for governance?

00:04:01.786 --> 00:04:05.746
Like how will decisions be made
are not yet answered right now from

00:04:05.746 --> 00:04:08.326
the, from the various posts on this.

00:04:08.746 --> 00:04:11.836
A quote is, the React team is
actively working on this new technical

00:04:11.836 --> 00:04:14.566
governance structure, and we'll
share more details in a future post.

00:04:14.656 --> 00:04:18.136
So this is an announcement of
a future announcement in some

00:04:18.136 --> 00:04:19.441
ways, but it's pretty real.

00:04:19.621 --> 00:04:22.766
So this is in collaboration with
the Open JS Foundation, which is

00:04:22.766 --> 00:04:24.356
a partner to the Linux Foundation.

00:04:24.356 --> 00:04:30.896
So like th these are very large, pretty
well-founded organizations that the React

00:04:30.896 --> 00:04:37.526
team is glomming onto in support of like
a neutral home for React, as they call it.

00:04:38.036 --> 00:04:42.776
It's sounds like they're in incorporating
React Native into this as well, which

00:04:42.776 --> 00:04:44.276
I think is not necessarily a given.

00:04:44.276 --> 00:04:48.056
You know, if you're talking about the
governance of React, what that means for

00:04:48.056 --> 00:04:50.456
React Native is not necessarily implied.

00:04:50.906 --> 00:04:54.266
But just looking at the founding
members like Amazon, Call Stack,

00:04:54.266 --> 00:04:58.586
Software Mansion, and Expo, and I
guess Microsoft too, like those are

00:04:58.586 --> 00:05:00.926
all heavy React native investors.

00:05:01.316 --> 00:05:05.096
Mo: I think it's quite surprising
in that sense because it's more

00:05:05.096 --> 00:05:07.106
heavy on the React native side.

00:05:07.586 --> 00:05:12.326
Like Vercel is really the key
sort of non-react native player.

00:05:12.326 --> 00:05:16.646
The rest are really heavy on React
Native and there's like noticeably

00:05:16.646 --> 00:05:20.846
missing membership from like Shopify
on the Remix side as an example.

00:05:21.341 --> 00:05:24.056
I, I actually find it's very skewed
towards React Native, almost shockingly.

00:05:24.566 --> 00:05:25.376
Carl: Yeah, I'd agree with that.

00:05:25.436 --> 00:05:27.261
It's, it is almost shockingly
skewed towards React.

00:05:27.266 --> 00:05:32.936
React Native, given that it was not really
pitched as the React Native foundation.

00:05:33.356 --> 00:05:34.016
That's true.

00:05:34.316 --> 00:05:38.366
I guess Software Mansion does do
a fair amount of web React work.

00:05:38.801 --> 00:05:42.101
But I, I believe Call Stack is
predominantly a React native shop as well.

00:05:42.281 --> 00:05:46.301
Mark: So I'll do my usual thing where
I, I step back and provide historical

00:05:46.301 --> 00:05:48.911
context and what matter at all.

00:05:49.421 --> 00:05:52.241
So React was invented at Facebook.

00:05:52.631 --> 00:05:57.221
It has always been a project
owned by Facebook and Meta.

00:05:57.731 --> 00:06:00.461
The code has been open source, but.

00:06:01.026 --> 00:06:05.526
You know, for years the entire
development team was Facebook meta

00:06:05.526 --> 00:06:09.096
employees paid by Meta to work on React.

00:06:09.666 --> 00:06:15.686
And I've said even in my conference
talks this year about Meta, Vercel, React

00:06:15.976 --> 00:06:19.866
ownership, that the React team has had
the freedom to work on what they want.

00:06:19.926 --> 00:06:24.816
And that's true, but I've, I was
reminded in some conversations with

00:06:24.816 --> 00:06:30.486
React team members at React Con, how
much their work is constrained by,

00:06:30.906 --> 00:06:35.226
like the fact that their performance
reviews are, "what have you done

00:06:35.226 --> 00:06:38.316
to further meta's goals this year?"

00:06:38.856 --> 00:06:44.646
And so in some ways their ability to push
React in the technical directions that

00:06:44.646 --> 00:06:49.986
they think are right, are limited by how
much they can make the case for that.

00:06:50.421 --> 00:06:55.281
Inside Meta, even something like
the Concurrent Stores work is

00:06:55.281 --> 00:06:59.481
essentially being pitched as, how
can we make Facebook's Ads Manager

00:06:59.481 --> 00:07:01.851
app faster in a lot of ways?

00:07:02.571 --> 00:07:07.041
So we saw multiple React team
members move over to Vercel.

00:07:07.101 --> 00:07:11.001
Like people used to complain that
this is all a Facebook app, all

00:07:11.001 --> 00:07:12.651
the meetings are inside Meta.

00:07:13.041 --> 00:07:16.161
There's no public roadmap, it's only meta.

00:07:16.671 --> 00:07:20.451
And then we had team members move to
Vercel, and then it became, well, now

00:07:20.451 --> 00:07:24.441
Vercel is applying too much ownership
to React and all the stuff we've talked

00:07:24.441 --> 00:07:28.821
about with Next and server components
and Vercel and how that's supposedly

00:07:28.821 --> 00:07:30.261
driving the roadmap, et cetera.

00:07:30.821 --> 00:07:34.751
And so the team itself has been
split across two companies,

00:07:35.261 --> 00:07:36.761
and they're working together.

00:07:36.821 --> 00:07:40.691
It's one team, but it's kind
of within these two companies.

00:07:41.201 --> 00:07:46.061
And so because of Reacts widespread
usage, there's been calls for many,

00:07:46.061 --> 00:07:50.771
many years that there ought to be
some kind of an independent foundation

00:07:51.221 --> 00:07:56.411
that would own the trademarks, the
rights, the development process.

00:07:56.846 --> 00:07:58.226
To React itself.

00:07:58.736 --> 00:08:00.866
And it always seemed kinda
like one of those pipe dreams.

00:08:01.106 --> 00:08:04.376
The calls on Twitter to
build, React into the browser.

00:08:04.496 --> 00:08:06.446
And obviously there's no
way that's going to happen.

00:08:06.671 --> 00:08:09.566
And, and this felt like much
of the same kind of idea.

00:08:10.046 --> 00:08:14.696
And so they, they did the initial
React and the initial keynote at

00:08:14.696 --> 00:08:17.426
React Con, and they were mostly
focusing on technical things.

00:08:17.426 --> 00:08:22.856
Like last year we, we fixed
the, the sibling preloading bug.

00:08:22.856 --> 00:08:26.636
That was the suspense gate problem that
everyone was talking about last year.

00:08:26.636 --> 00:08:30.116
And 19.2 came out and the compiler is 1.0.

00:08:30.626 --> 00:08:34.226
And then Seth came out and he
did the one more thing routine

00:08:34.736 --> 00:08:40.526
and as soon as he put the React
Foundation slide up, my jaw dropped.

00:08:40.766 --> 00:08:44.006
And I think I even said out loud,
oh my word, they actually did it.

00:08:44.546 --> 00:08:49.256
And my first reaction
was, even without knowing.

00:08:49.796 --> 00:08:53.906
Any actual details about what the
foundation is or how it's going

00:08:53.906 --> 00:08:57.086
to work or whether this is even
going to work out in practice.

00:08:57.596 --> 00:09:02.426
The fact that they have taken the time
to do the legal preparation work to try

00:09:02.426 --> 00:09:08.486
to make this happen and are actually
attempting to execute on that is a

00:09:08.486 --> 00:09:11.996
huge deal for React and the ecosystem.

00:09:12.446 --> 00:09:17.906
It, it is a statement of good
faith and intent for how they want

00:09:17.906 --> 00:09:20.066
React to proceed in the future.

00:09:20.456 --> 00:09:25.526
Like without any details, my
immediate reaction is, yes, finally,

00:09:25.526 --> 00:09:27.206
this is a good step forward.

00:09:27.716 --> 00:09:32.396
We'll see what it means in practice,
but this is a really big deal.

00:09:32.936 --> 00:09:34.616
Carl: Yeah, I would agree with that.

00:09:34.676 --> 00:09:37.466
It's a really big deal that
they're moving in this direction.

00:09:37.766 --> 00:09:41.396
I'm really curious about the details
because I think there's a lot of, I

00:09:41.396 --> 00:09:44.996
don't know, like in the past they've
done working groups and et cetera.

00:09:45.401 --> 00:09:48.671
And my understanding of the takeaway
is generally, has generally been

00:09:48.671 --> 00:09:54.101
that they found it really difficult
to manage participation in those

00:09:54.101 --> 00:09:56.321
like open access kind of arenas.

00:09:56.771 --> 00:10:01.121
So maybe the, this is kind of like adding
a new layer of abstraction perhaps with

00:10:01.811 --> 00:10:08.291
administrative support from currently
thriving independent foundations.

00:10:08.591 --> 00:10:08.681
Mm-hmm.

00:10:08.921 --> 00:10:13.391
So that, that definitely makes me
think that this has a real chance

00:10:13.391 --> 00:10:17.471
of being something real and valuable
that goes on for a long time.

00:10:17.981 --> 00:10:22.091
I'm curious what it means for things
like, like in practice, it's not

00:10:22.091 --> 00:10:23.891
like anyone's employer is changing.

00:10:23.951 --> 00:10:25.391
No details have been shared yet.

00:10:25.391 --> 00:10:29.441
At least that anyone is being
paid from this new foundation.

00:10:29.771 --> 00:10:34.061
I, I don't know whether to call it meta or
Facebook 'cause it's on the fb.com domain.

00:10:34.241 --> 00:10:34.361
Mm-hmm.

00:10:34.601 --> 00:10:37.721
But in the Facebook engineering
announcement here, they do say that Meta

00:10:37.721 --> 00:10:41.531
has committed to a five year partnership
with over $3 million in funding.

00:10:42.146 --> 00:10:43.586
I don't know what other
funding they might have.

00:10:43.586 --> 00:10:45.986
I don't know what other sources of
funding they might have in the future,

00:10:45.986 --> 00:10:51.896
but like just looking at five years,
$3 million, like that's 600,000 per

00:10:51.896 --> 00:10:56.816
year, which is like, you know, for meta
engineers, that's like free engineers.

00:10:57.296 --> 00:10:58.826
So I don't know.

00:10:58.826 --> 00:11:01.556
I don't know what that means for
people's incentives and where they

00:11:01.556 --> 00:11:04.736
will work and how their focus and
performance will be evaluated.

00:11:04.796 --> 00:11:05.006
Yeah.

00:11:05.366 --> 00:11:10.136
Mo: What that rules out is that
effectively the React Native or React and

00:11:10.136 --> 00:11:14.246
React Native Core teams will definitely
not be unemployed by the React Foundation.

00:11:14.531 --> 00:11:14.881
Right.

00:11:14.886 --> 00:11:18.236
'cause that would basically cover
three salaries, which is far smaller

00:11:18.236 --> 00:11:19.466
than what the React teams are.

00:11:19.826 --> 00:11:22.436
Carl: I think the React core
team has like 10 engineers.

00:11:22.486 --> 00:11:23.446
Mo: And RN is about the same.

00:11:23.446 --> 00:11:24.586
So you're talking 20 engineers.

00:11:24.586 --> 00:11:28.066
It's definitely not going to
cover those employees to move them

00:11:28.066 --> 00:11:30.436
over, which is in some capacity.

00:11:30.796 --> 00:11:32.386
And then details are to be fleshed out.

00:11:32.386 --> 00:11:35.416
But in some capacity it is a bit
disappointing because it would be great

00:11:35.416 --> 00:11:40.666
if they had more freedom as the React
Native Core team to play around without

00:11:40.666 --> 00:11:43.756
the restrictions, like you mentioned,
of the reviews that Meta has internally.

00:11:44.131 --> 00:11:47.401
And so it's gonna be interesting
to see how that Dyna dynamic plays

00:11:47.401 --> 00:11:49.741
out effectively because there is
still gonna be that same team.

00:11:49.981 --> 00:11:50.551
At Meta

00:11:51.016 --> 00:11:54.151
Mark: I, I have three sources
of information that I'm piecing

00:11:54.151 --> 00:11:57.901
together for some of how the
foundation is supposed to work.

00:11:58.381 --> 00:12:02.641
Seth Webster answered a few questions
about this during the q and a session

00:12:02.731 --> 00:12:05.291
that was broadcast at React Conf.

00:12:05.731 --> 00:12:11.041
I had a conversation with a couple
React team members and the topic came

00:12:11.041 --> 00:12:12.541
up about how things would be governed.

00:12:13.081 --> 00:12:17.011
And then there was an article on
the new stack where Seth Perry was

00:12:17.131 --> 00:12:21.421
interviewed and was giving some further
details about some of the governance.

00:12:21.871 --> 00:12:24.841
So as best I understand it, so
you've got kind of the corporate

00:12:24.841 --> 00:12:28.591
level stuff that's Meta, Amazon,
Callstack, Vercel, et cetera.

00:12:29.131 --> 00:12:33.091
They will then elect a
technical steering committee.

00:12:33.421 --> 00:12:38.431
Which is, I guess sort of similar
to how Node and other projects work,

00:12:39.061 --> 00:12:45.181
Seth said in the q and a, that meta
will start with five votes on that

00:12:45.181 --> 00:12:50.041
corporate board, and then it will go
down to one over the next five years.

00:12:50.131 --> 00:12:53.191
So you kind of a decreasing
amount of influence in that sense.

00:12:53.581 --> 00:12:57.751
The technical steering committee, I
assume, would be able to make decisions

00:12:58.261 --> 00:13:02.911
themselves, but obviously the fact that
they are employees of the companies

00:13:03.151 --> 00:13:08.071
elected by those companies, et cetera,
they would be taking their company's

00:13:08.071 --> 00:13:09.876
interests into account in the process.

00:13:10.861 --> 00:13:15.211
The article says that the
technical governance will be in

00:13:15.211 --> 00:13:17.071
the open more than it once was.

00:13:17.071 --> 00:13:20.341
Request for comments,
sets of stages, et cetera.

00:13:20.641 --> 00:13:23.881
But a lot of the process
is still to be figured out.

00:13:24.391 --> 00:13:28.681
The article also talks about the
foundation doing things like investing

00:13:28.681 --> 00:13:34.891
in React hubs, helping boot camps teach
React better, possibly some things with

00:13:34.981 --> 00:13:37.621
conferences and alignment and such.

00:13:38.041 --> 00:13:43.651
So it sounds like the foundation is
going to be doing more outreachy things.

00:13:43.651 --> 00:13:47.581
So there, there's a lot of this
that is not clear what it means

00:13:47.581 --> 00:13:49.981
in practice yet, but certainly.

00:13:50.776 --> 00:13:55.516
React is not solely a meta
owned thing at this point.

00:13:55.876 --> 00:13:58.096
There are multiple companies
that are invested in it.

00:13:58.486 --> 00:14:04.096
There is a, a future for React
independent of META'S ownership and goals.

00:14:04.576 --> 00:14:10.606
And this all feels like the people who
care are trained to do the right thing.

00:14:11.116 --> 00:14:11.326
And

00:14:11.656 --> 00:14:14.596
Mo: on the conference side, I mean, I
hope that's the case because one of the,

00:14:14.896 --> 00:14:18.676
as a conference organizer, one of the
things that's perhaps challenging is

00:14:18.676 --> 00:14:24.106
that Meta doesn't necessarily sponsor any
conferences beyond just React conf, right?

00:14:24.136 --> 00:14:26.776
And so, look, it's well known
that that's sort of the case.

00:14:26.776 --> 00:14:31.516
And so maybe the React Foundations
that is going to be able to sponsor

00:14:31.516 --> 00:14:36.046
those conferences, even if it's
not a meta badge to speak, which

00:14:36.046 --> 00:14:38.536
would be very, very interesting
if some of that is used for that.

00:14:38.716 --> 00:14:40.486
So I'm sure it's not just
Meta who's investing, right?

00:14:40.486 --> 00:14:43.516
Like I, I suspect that there's
funding coming in from.

00:14:44.101 --> 00:14:47.341
Amazon and Microsoft, at least
from the bigger, bigger sort

00:14:47.341 --> 00:14:49.051
of established enterprises

00:14:49.531 --> 00:14:50.071
Carl: hopefully.

00:14:50.071 --> 00:14:50.911
And that's interesting.

00:14:51.121 --> 00:14:55.591
And the new Stack article interviewed
Seth and has a bunch of poll quotes

00:14:55.591 --> 00:14:58.561
from him and they do talk about that,
that like the foundation will look

00:14:58.561 --> 00:15:00.481
at expanding the annual React conf.

00:15:00.511 --> 00:15:03.271
I guess that's not sponsoring
other conferences, but they're

00:15:03.271 --> 00:15:04.621
talking about conferences at least.

00:15:04.921 --> 00:15:06.601
But also something that
caught my attention.

00:15:06.631 --> 00:15:09.721
They say while React Comp is one of the
few conferences that actually makes a

00:15:09.721 --> 00:15:12.121
profit, it basically only paid for itself.

00:15:12.721 --> 00:15:14.971
And also it's a thousand
dollars a ticket conference.

00:15:14.971 --> 00:15:20.881
So like hopefully the mode of making
conferences self-sustaining is not

00:15:20.911 --> 00:15:22.381
making them cost a thousand dollars.

00:15:22.891 --> 00:15:23.221
Mo: Yeah.

00:15:23.311 --> 00:15:27.541
I mean conferences are from experience
a very, very expensive endeavor.

00:15:27.541 --> 00:15:30.631
And if you don't have companies
backing them, they will make a loss.

00:15:31.121 --> 00:15:34.451
Carl: I do wanna shout out, as we
mentioned at the start, Seth says

00:15:34.481 --> 00:15:36.701
"We have lots of boot camps out there
that are doing their best, but they're

00:15:36.701 --> 00:15:39.911
also sending people out into the world
misinformed about how React works."

00:15:40.211 --> 00:15:41.561
This is interesting there.

00:15:41.621 --> 00:15:44.021
It's a, it's funny, they're actually
hitting on a couple of points

00:15:44.021 --> 00:15:49.181
that I've investigated myself
about how to do businesses in

00:15:49.181 --> 00:15:53.831
like a community since like I had
previously connected with a bootcamp.

00:15:53.981 --> 00:15:57.911
Somebody was working there as
the curriculum lead and they

00:15:57.911 --> 00:15:59.291
were doing a curriculum overhaul.

00:15:59.321 --> 00:16:01.931
'cause they hadn't changed what they
were teaching in three or four years.

00:16:01.931 --> 00:16:03.701
And they were like, is
this still relevant?

00:16:03.731 --> 00:16:05.111
Is this what the industry's using?

00:16:05.596 --> 00:16:06.406
And I was like, cool.

00:16:06.406 --> 00:16:07.426
I help run a community.

00:16:07.426 --> 00:16:08.566
I know lots of experts.

00:16:08.926 --> 00:16:12.526
I would be happy to facilitate
some kind of professional review.

00:16:13.006 --> 00:16:17.176
And then the bootcamp curriculum lead
got laid off because that was 2022

00:16:17.206 --> 00:16:18.976
and lots of things were not happening.

00:16:18.976 --> 00:16:22.006
So it's interesting to see them talk about
things that I've thought a lot about.

00:16:22.636 --> 00:16:27.766
And also a lovely shout out, Seth says
there are also cohorts such as meetups

00:16:27.796 --> 00:16:29.236
and local groups that could be assisted.

00:16:29.266 --> 00:16:32.566
One meetup actually led to the creation
of the conference React Native London.

00:16:32.986 --> 00:16:34.276
So that's super cool.

00:16:34.336 --> 00:16:35.326
Love that for you, Mo.

00:16:36.226 --> 00:16:39.016
Mo: Yeah, I didn't, I, I did not
have that on my Bingo card to get

00:16:39.016 --> 00:16:42.436
a shout out from Seth Webster on
an interview, which is awesome.

00:16:43.006 --> 00:16:44.176
Yeah, it was good to have him last year.

00:16:44.656 --> 00:16:48.166
Carl: Mo is the organizer of
React Native London and that one

00:16:48.166 --> 00:16:49.516
meetup that led to the creation.

00:16:49.516 --> 00:16:51.106
So that, that's just fun.

00:16:51.106 --> 00:16:51.616
That's cool.

00:16:51.796 --> 00:16:54.496
We have actual players in the
ecosystem in the podcast right now.

00:16:55.726 --> 00:16:56.416
Mo: Well, you got Mark.

00:16:56.416 --> 00:16:59.386
So I'm stepping up to very,
very, very high standards.

00:16:59.731 --> 00:17:00.361
Pretending to.

00:17:00.811 --> 00:17:01.231
Carl: Cool though.

00:17:01.231 --> 00:17:01.351
Yeah.

00:17:01.351 --> 00:17:02.041
So I don't know.

00:17:02.071 --> 00:17:03.301
I don't know if there's more to say there.

00:17:03.631 --> 00:17:04.891
Mark: Some of the more technical stuff.

00:17:04.981 --> 00:17:08.371
So they, they talked about React
19.2 coming out, which if you've been

00:17:08.371 --> 00:17:10.981
paying attention to this podcast for
the last several months, you would've

00:17:10.981 --> 00:17:12.631
known all the details already.

00:17:12.991 --> 00:17:17.401
Like the new activity component for being
able to hide components while persisting

00:17:17.401 --> 00:17:23.431
state use effect event for hopefully
fewer use effect related bugs, et cetera.

00:17:23.941 --> 00:17:27.541
React compiler hit 1.0 and then

00:17:27.601 --> 00:17:31.891
Mo as like as usual, you wanna talk
about the React Native-y things?

00:17:32.371 --> 00:17:37.876
Mo: So a few updates that they did, one
of which was quite surprising was that

00:17:38.041 --> 00:17:43.771
the next release of React native version
0.82 is going to be new architecture only.

00:17:44.071 --> 00:17:46.891
So obviously earlier on a few
months ago, we talked about how they

00:17:47.071 --> 00:17:50.011
deprecated the old architecture than
they froze the old architecture.

00:17:50.221 --> 00:17:52.231
Now they're dropping the old architecture.

00:17:52.591 --> 00:17:55.921
And so to me that was a much
faster deprecation cycle

00:17:55.921 --> 00:17:57.571
than I, I would've expected.

00:17:57.991 --> 00:18:02.491
Specifically when it comes to the fact
that there are still a fair few libraries

00:18:02.761 --> 00:18:06.391
that are using the old architecture
and only support the old architecture.

00:18:06.391 --> 00:18:10.351
So to give you a very concrete
example, we had our monthly meetup

00:18:10.411 --> 00:18:15.031
literally yesterday, and there was
a talk about Arrive, which is this

00:18:15.031 --> 00:18:17.791
animation engine that a lot of people
are using to animate websites and

00:18:17.791 --> 00:18:19.021
make really, really cool stuff.

00:18:19.351 --> 00:18:24.091
But what we learned surprisingly was that
Rive only supports the old architecture.

00:18:24.361 --> 00:18:28.171
So what that means is that this company
who's a very popular healthcare company,

00:18:28.171 --> 00:18:31.921
really don't have a path to sort of
migrate to the new architecture and

00:18:31.921 --> 00:18:36.871
hence version 0.82 until Rive starts
to support the new architecture.

00:18:37.231 --> 00:18:41.131
So there are still libraries, albeit
the majority of major libraries have

00:18:41.131 --> 00:18:44.701
been ported to the new architecture
that are still hanging behind.

00:18:44.701 --> 00:18:47.731
So I'm quite surprised by this,
but we'll see how it goes.

00:18:47.731 --> 00:18:50.821
It probably means that these library
maintainers really need to like step up

00:18:50.821 --> 00:18:52.471
in the next month or two and get ready.

00:18:52.921 --> 00:18:56.731
The second big thing, which I have
a little bit about later on, but

00:18:56.791 --> 00:19:02.551
just a quick one, is that Amazon did
the Vega Os announcement earlier.

00:19:02.611 --> 00:19:04.771
It was towards the end of September
that they actually announced it,

00:19:04.771 --> 00:19:08.281
but they formally talked to the
React and React native communities

00:19:08.281 --> 00:19:10.011
about it during React Conf.

00:19:10.291 --> 00:19:15.601
This is a completely new operating system
that's fully built from scratch by Amazon

00:19:15.601 --> 00:19:18.211
folks and React Native is the UI layer.

00:19:18.211 --> 00:19:21.931
It's the only way that you can write
apps for it, which is quite a big

00:19:21.931 --> 00:19:26.641
investment from Amazon's perspective
into React Native as a technology.

00:19:27.121 --> 00:19:29.371
So Amazon makes a lot of devices.

00:19:29.401 --> 00:19:32.581
For a little bit of context, you might've
seen their Fire TV devices, some of the

00:19:32.581 --> 00:19:37.111
Kindle fire devices that they had, but
also like Echo dots and a whole slew of

00:19:37.111 --> 00:19:39.151
different devices that they manufacture.

00:19:39.511 --> 00:19:43.111
And previously a lot of these were
running on Android or a variety of Android

00:19:43.111 --> 00:19:46.741
called Fire Os that they had adopted
from the Android open source projects.

00:19:47.191 --> 00:19:50.821
And so now they've kind of completely
ditched that and they're betting

00:19:50.821 --> 00:19:55.141
long term on React native now at our
company at Theo and a bunch of other

00:19:55.141 --> 00:19:58.351
companies have been sort of working
with Amazon behind the scenes on this.

00:19:58.351 --> 00:20:01.141
And we're aware of this but weren't
really allowed to speak about it.

00:20:01.291 --> 00:20:02.401
So it's now out in the public.

00:20:02.401 --> 00:20:06.271
But it has been a good while, which I
cannot specify how long that duration is

00:20:06.541 --> 00:20:09.631
that I have been aware of this, but just
not able to talk about it and have been

00:20:09.631 --> 00:20:12.781
working with the Amazon folks to make sure
that things are ready for their launch.

00:20:12.931 --> 00:20:15.391
So they have an introduction video
at React Con, which I think is

00:20:15.391 --> 00:20:21.271
interesting because TV apps need
to run on very, very limited specs.

00:20:21.271 --> 00:20:24.391
You're talking like a few gigs of
Ram one or two gigs of ram and like

00:20:24.391 --> 00:20:28.111
very, very, very slow CPUs and some
of them are even worse than that.

00:20:28.381 --> 00:20:32.911
So effectively they really had to
optimize the living crap out of their

00:20:32.911 --> 00:20:36.811
operating system and make sure that
React plays nice with it and is like the

00:20:36.811 --> 00:20:38.761
first class citizen when it comes to it.

00:20:38.761 --> 00:20:40.921
So it's, it's very interesting
how they had to optimize it and

00:20:40.921 --> 00:20:42.031
it was a big undertaking for them.

00:20:42.031 --> 00:20:42.271
So.

00:20:42.691 --> 00:20:45.691
I guess congrats to the Amazon team,
but beyond that, it's quite interesting

00:20:45.691 --> 00:20:48.361
for people that are interested in
performance and React and React native.

00:20:48.811 --> 00:20:51.991
Carl: Yeah, I was just scanning this
to see if I could find any details

00:20:51.991 --> 00:20:55.021
about what they built on top of,
because like, I don't know, nobody

00:20:55.021 --> 00:20:57.211
builds a whole OS from scratch anymore.

00:20:57.211 --> 00:20:59.101
And this is on top of Linux?

00:20:59.521 --> 00:21:01.381
Mo: Yeah, it's c plus
plus on top of Linux.

00:21:01.381 --> 00:21:02.551
Basically it's a Linux.

00:21:03.211 --> 00:21:04.861
Or is a Unix based system.

00:21:05.401 --> 00:21:07.321
Carl: Right, like, and so is Android.

00:21:07.711 --> 00:21:14.401
Like, I'm curious to what extent this
is a locked down, stripped back version

00:21:14.401 --> 00:21:16.561
of Android that they're calling Vega.

00:21:16.831 --> 00:21:20.221
They don't say that anywhere, but
like reading the tea leaves here,

00:21:20.221 --> 00:21:23.641
I, my assumption is that the, I
don't know, Android was such a

00:21:23.641 --> 00:21:28.141
massive undertaking that Google
then acquired and commercialized.

00:21:28.561 --> 00:21:32.551
Curious to hear more technical details
about the OS layer here and how it…

00:21:32.611 --> 00:21:35.131
Mo: I can tell you a little bit about that
because I've known about it for a while.

00:21:35.311 --> 00:21:37.771
It's not on top of
Android in any capacity.

00:21:38.071 --> 00:21:41.341
It is fully, the Android open
source project components of

00:21:41.341 --> 00:21:42.301
it are fully stripped out.

00:21:42.301 --> 00:21:46.771
It's built from scratch, which means
that compatibility with old apps is.

00:21:47.281 --> 00:21:49.231
Limited and there's other solutions.

00:21:49.291 --> 00:21:51.931
It's not that you can run Android
apps on it as an example that

00:21:51.931 --> 00:21:53.851
we're the old Fire OS apps.

00:21:54.151 --> 00:21:57.931
Carl: So wait, it sounds a little bit like
you're saying there is a shared lineage

00:21:57.931 --> 00:22:02.731
with Android, but it's different enough
that its own technically distinct thing.

00:22:02.821 --> 00:22:07.141
Mo: They share a technical lineage in
the same capacity that like Mac Os and

00:22:07.141 --> 00:22:11.011
Androids here, which is, they are both
unique systems and that's pretty much it.

00:22:11.011 --> 00:22:15.331
Like they serve the same kernel but
like so does 90% of devices out there.

00:22:15.451 --> 00:22:19.306
So it's as Android, as IOS's,
Android, if that kind of makes sense.

00:22:19.996 --> 00:22:21.796
Carl: The Tree of Life,
kingdom Family order.

00:22:21.796 --> 00:22:23.686
Like this is not shared genus.

00:22:23.686 --> 00:22:25.546
This is shared order maybe?

00:22:25.756 --> 00:22:26.146
Yes.

00:22:26.236 --> 00:22:26.776
Okay, cool.

00:22:26.776 --> 00:22:27.166
Good to know.

00:22:27.166 --> 00:22:27.556
Thank you.

00:22:27.796 --> 00:22:30.976
Mark: I do wanna highlight a couple talks
in particular, and again, you can look at

00:22:30.976 --> 00:22:35.446
the whole React con recap blog posts to
get links to the different talks and the

00:22:35.446 --> 00:22:36.676
different portions of the live stream.

00:22:36.946 --> 00:22:40.846
A lot of good talks that were worth
watching, but two that I liked in

00:22:40.846 --> 00:22:45.316
particular, Joe Savona did a talk on
some of the React team's performance

00:22:45.316 --> 00:22:49.906
experiments, and there's a bit of
controversy because he showed a bunch of

00:22:49.906 --> 00:22:54.856
hypothetical, semi hypothetical benchmark
numbers without any real details on the

00:22:54.856 --> 00:22:56.746
actual implementation of the benchmarks.

00:22:56.806 --> 00:23:00.886
And then some of them were like,
versus we built NAP with signals

00:23:00.886 --> 00:23:05.986
and compared it with one with React
and then ex a highly prototype

00:23:05.986 --> 00:23:07.696
React and a bunch of other stuff.

00:23:08.026 --> 00:23:12.136
And then people were saying, well, we
tried to mimic this and we think you're

00:23:12.136 --> 00:23:13.576
probably using signals the wrong way.

00:23:13.846 --> 00:23:18.271
But it was still interesting to
hear the discussion around, we agree

00:23:18.271 --> 00:23:22.141
that performance has been a problem
and we've tried prototyping some

00:23:22.141 --> 00:23:26.161
different ideas to see what's possible
and where bottlenecks might be.

00:23:26.671 --> 00:23:30.991
The other one I really wanna point to
though, Rick Hanlon did a talk called

00:23:31.051 --> 00:23:36.331
Async React and he had a few major, he
had a couple different points out of this.

00:23:36.631 --> 00:23:40.531
One was that the React team has been
talking about things like suspense and

00:23:40.531 --> 00:23:47.071
concurrency since 2018, and if it's been
hard to follow where the React team is

00:23:47.071 --> 00:23:51.931
trained to go with this, it's 'cause
the React team itself really didn't know

00:23:52.021 --> 00:23:53.431
where they were trained to go with this.

00:23:53.431 --> 00:24:01.021
He even pulled out meeting notes from a
React team weekly meeting in like 2015 or

00:24:01.021 --> 00:24:08.851
2016 where they started having the first
initial ideas for, we think we want to go

00:24:08.851 --> 00:24:13.831
in this direction, but they really didn't
know what the final result ought to look

00:24:13.831 --> 00:24:15.391
like or how they were going to get there.

00:24:15.886 --> 00:24:20.626
And so showed a diagram with a
whole bunch of back and forth wavy

00:24:20.626 --> 00:24:24.946
lines like we, we don't know where
we're going, but now it's 2025.

00:24:25.006 --> 00:24:26.956
We've gotten through the confusion.

00:24:27.316 --> 00:24:32.086
We've now built all the main concurrent
pieces that we were trained to build.

00:24:32.446 --> 00:24:37.066
We are seeing the results of even
like the React 16 fiber rerate.

00:24:37.576 --> 00:24:42.646
And now we can actually say, we've
built these pieces and here's

00:24:42.646 --> 00:24:43.966
how they ought to fit together.

00:24:44.476 --> 00:24:49.456
And so the second half of his talk
was a demo where he took a badly

00:24:49.456 --> 00:24:53.296
written but viable React app, which
uses use effect for data fetching

00:24:53.296 --> 00:24:56.626
and manual setting, state for
loading states and things like that.

00:24:56.926 --> 00:25:02.296
And he first refactored it to have
a bunch of transitions for better

00:25:02.296 --> 00:25:08.056
loading animations, using suspense for
the data fetching, and he showed the

00:25:08.056 --> 00:25:10.906
visible improvements in user experience.

00:25:11.476 --> 00:25:17.206
And then his point towards the end was
that, yeah, the, so like this is how

00:25:17.326 --> 00:25:21.226
modern Async React code ought to work.

00:25:21.736 --> 00:25:26.236
But in fact, you shouldn't even have
to write most of this code in your

00:25:26.236 --> 00:25:30.916
own app because the transitions and
the loading states and everything else

00:25:31.186 --> 00:25:36.316
really ought to be embedded in your
router and your data fetching library.

00:25:36.796 --> 00:25:41.356
Now, unfortunately, his actual talk got
interrupted for stupid technical reasons.

00:25:41.626 --> 00:25:46.426
So he came back at the end of day two and
picked up with his demo and actually had

00:25:46.426 --> 00:25:48.106
a chance to do a better version of it.

00:25:48.631 --> 00:25:53.191
And so I think the key points are,
one, the React team has now built

00:25:53.191 --> 00:25:55.771
the concurrent async features that
they've talked about for years.

00:25:56.251 --> 00:26:02.949
Two, a lot of us, including myself, are
still kind of stuck in like a 20 16, 20

00:26:02.949 --> 00:26:06.841
18 era mindset of how to use React three.

00:26:06.871 --> 00:26:11.701
These things make writing React apps
better and better user experience.

00:26:12.211 --> 00:26:17.671
Four, we need to get these things
embedded in component libraries and

00:26:17.671 --> 00:26:22.651
data fetching libraries so that a lot
of this stuff just works outta the box.

00:26:23.041 --> 00:26:26.371
So I highly, highly recommend
watching Ricky's talk.

00:26:26.641 --> 00:26:28.861
He also put up the demo code as well.

00:26:29.281 --> 00:26:30.031
Carl: That was a good talk.

00:26:30.091 --> 00:26:30.871
It was a good demo.

00:26:31.441 --> 00:26:34.141
I will say, while watching
him write the code.

00:26:34.711 --> 00:26:36.811
I was like, man, this
looks really complicated.

00:26:37.021 --> 00:26:37.381
Mark: Yeah.

00:26:37.381 --> 00:26:39.631
And that, and that's another point that
we're going to touch on here with a

00:26:39.631 --> 00:26:41.191
couple of the, the other things as well.

00:26:41.401 --> 00:26:45.661
One other thing that really caught my
attention, so if you've been listening

00:26:45.661 --> 00:26:49.471
to podcasts for a while, you've heard
me agitating, saying that we really

00:26:49.471 --> 00:26:55.171
need is a new React working group
where folks from the community can

00:26:55.171 --> 00:26:58.441
officially communicate to the React team
for things like, Hey, we think there

00:26:58.441 --> 00:27:00.211
should be more docs to cover this topic.

00:27:00.631 --> 00:27:03.121
Or, oops, create React app just broke.

00:27:03.121 --> 00:27:05.191
I think you should fix
it, and things like that.

00:27:05.701 --> 00:27:11.161
And Ricky was actually the person who
drove most of the React eight team.

00:27:11.491 --> 00:27:12.001
Working group.

00:27:12.721 --> 00:27:16.051
And so at the end of his talk, Ricky
actually announced that there is

00:27:16.051 --> 00:27:19.711
now a new Async React working group.

00:27:20.401 --> 00:27:26.371
And this is sort of a catchall, it's meant
to cover discussions of things like how

00:27:26.371 --> 00:27:32.576
do we get async React features into major
ecosystem libraries and, what kind of

00:27:32.576 --> 00:27:34.826
docs should we have to cover this stuff?

00:27:35.216 --> 00:27:39.626
And so the, even the first discussion
thread is a lot of discussion between me,

00:27:39.656 --> 00:27:45.566
Ricky, Dan Aberman of Corbin Crutchley,
about a whole bunch of possible docs,

00:27:45.566 --> 00:27:50.126
pages that we could add that would
cover things like transitions and

00:27:50.126 --> 00:27:52.586
suspense and how to use them correctly.

00:27:53.066 --> 00:27:57.206
And getting people from the community
to contribute those new docs pages

00:27:57.206 --> 00:27:58.796
rather than waiting on the React team.

00:27:59.086 --> 00:27:59.566
To write them.

00:28:00.166 --> 00:28:03.496
So I am actually genuinely,
genuinely excited.

00:28:03.556 --> 00:28:09.226
Like I've done a lot of complaining
and this is the answer to my complaints

00:28:09.256 --> 00:28:14.776
that we have working group and docs
plans and an agreement that people

00:28:14.776 --> 00:28:16.516
outside the team can contribute.

00:28:16.996 --> 00:28:20.746
So like I am actually
legitimately thrilled by this.

00:28:21.316 --> 00:28:21.766
Carl: Nice.

00:28:22.156 --> 00:28:26.506
I do appreciate more, I don't know, open
participation more, more discussion.

00:28:26.986 --> 00:28:27.406
That's great.

00:28:27.796 --> 00:28:29.446
Should we get into Remix V three?

00:28:29.956 --> 00:28:30.796
Mark: Yes, we should.

00:28:31.036 --> 00:28:35.176
Alright, so usual caveat, I still
have not had time to actually watch

00:28:35.386 --> 00:28:39.346
the announcement, but I, I think
I can give a fair summary of it

00:28:39.406 --> 00:28:43.186
from having seen the discussion on
Twitter and the articles afterwards.

00:28:43.366 --> 00:28:46.756
We have mentioned for the last
several months that they were teasing

00:28:46.786 --> 00:28:51.616
Remix V three is going to be, not
pre-ACT, its own component model,

00:28:51.766 --> 00:28:54.046
something with iframes, whatever.

00:28:54.436 --> 00:28:58.246
And our last comments on it were
just show us some code already.

00:28:58.906 --> 00:29:02.806
Well, at the Remix Jam conference,
they did actually show us the code.

00:29:03.376 --> 00:29:09.466
There was a, a repo put together that did
timestamped links to all the appropriate

00:29:09.466 --> 00:29:11.626
pieces of the announcement video.

00:29:12.136 --> 00:29:16.906
So if you'd like to be able to jump
in and see the examples of what Remix

00:29:16.906 --> 00:29:19.786
V three code is supposed to look
like, that should make it easier.

00:29:20.296 --> 00:29:25.336
My first impressions, again, just
having seen screenshots of the code in

00:29:25.336 --> 00:29:30.496
following the discussions, is that Remix
v three's component model is sort of a

00:29:30.496 --> 00:29:34.756
mixture between React, view and backbone.

00:29:35.446 --> 00:29:38.806
So it's kind of like React in
that you have function components

00:29:38.866 --> 00:29:40.456
and they, and that uses JSX.

00:29:41.056 --> 00:29:45.856
It's kind of like view and the
composition API, where you're

00:29:45.856 --> 00:29:48.676
given a closure as the setup.

00:29:49.151 --> 00:29:53.741
It's a little bit like backbone
in that the function component

00:29:53.741 --> 00:29:58.241
you're rating still sort of is
organized like as if it were a class.

00:29:58.571 --> 00:30:03.641
It passes in a reference to the
instance rather than getting

00:30:03.641 --> 00:30:08.111
the props as an argument, and
you're supposed to call it this.

00:30:08.591 --> 00:30:12.401
And part of that is to make use
of a TypeScript typing trick that

00:30:12.401 --> 00:30:15.881
lets you declare the type of this
as an argument to a function.

00:30:16.481 --> 00:30:23.351
But also you manually trigger
updates by first mutating a variable

00:30:23.471 --> 00:30:28.811
in the setup closure, and then
you manually call this update.

00:30:29.411 --> 00:30:34.901
And so Ryan Florence even said, this
is basically old school React class

00:30:34.901 --> 00:30:36.821
component, this dot force update.

00:30:37.306 --> 00:30:42.766
Essentially, so I, I can see bits and
pieces of parallels and influences

00:30:42.766 --> 00:30:45.076
between all three of those frameworks.

00:30:45.076 --> 00:30:49.396
When I look at the Remix code,
it's also supposed to come with a

00:30:49.396 --> 00:30:54.196
bunch of utilities for being able
to compose event handlers together.

00:30:54.856 --> 00:30:59.086
And yeah, so we, we have
finally seen the code.

00:30:59.476 --> 00:31:03.646
I believe they also gave some
demonstrations of what the server side

00:31:03.646 --> 00:31:05.986
loading story is supposed to look like.

00:31:06.286 --> 00:31:12.136
Some kind of an I frame alike
component that has its own URL and

00:31:12.136 --> 00:31:14.416
can automatically re fetch HTML.

00:31:14.476 --> 00:31:18.976
I haven't looked into those pieces
as much, so very big picture.

00:31:19.126 --> 00:31:23.206
I saw a lot of people arguing
about having this dot update.

00:31:23.831 --> 00:31:28.121
A lot of people saying it feels like a
step backwards, it's manual update code.

00:31:28.691 --> 00:31:33.101
But some people demonstrated that you can
very quickly write your own wrappers that

00:31:33.101 --> 00:31:34.811
just call this DOT update internally.

00:31:35.081 --> 00:31:38.771
I have seen wrappers that
mimic like the used state hook.

00:31:39.101 --> 00:31:43.391
I've seen wrappers for other state
management libraries like Redux.

00:31:43.751 --> 00:31:48.551
So it's a primitive that can clearly
be abstracted if you really want to.

00:31:48.911 --> 00:31:53.291
I saw some good posts and articles
from James Long and a couple other

00:31:53.291 --> 00:31:58.421
people with thoughts on the ability
to compose interactions together.

00:31:58.961 --> 00:32:03.131
Carl, to your point that modern
React and all the new async

00:32:03.131 --> 00:32:06.131
features feel very complicated.

00:32:06.431 --> 00:32:11.981
Like there's good reasons why methods
like transitions exist to try to give

00:32:11.981 --> 00:32:17.411
better user experiences, but it's just all
these additional concepts and behaviors

00:32:17.411 --> 00:32:19.661
you have to keep track of in your head.

00:32:20.176 --> 00:32:27.226
And Remix is trying to go for a less
magic, less abstraction approach.

00:32:27.706 --> 00:32:31.156
So we'll see what it means
in terms of adoption.

00:32:31.276 --> 00:32:36.496
Again, this is non-reactive, so
different framework, different ecosystem.

00:32:36.496 --> 00:32:40.366
Who knows what the actual adoption
will look like, but I get the sense

00:32:40.366 --> 00:32:44.356
of what they're trying to go for
and I, I think it will appeal to

00:32:44.446 --> 00:32:49.306
some number of users out there that
want to have that kind of behavior.

00:32:49.816 --> 00:32:53.026
Carl: Yeah, I'll definitely keep
paying attention to it 'cause

00:32:53.026 --> 00:32:58.066
they're thoughtful about things and
historically have just done a lot.

00:32:58.456 --> 00:33:00.496
So I'm very curious to
see where this goes.

00:33:00.496 --> 00:33:07.336
But my gut feeling here is that this is
going to end up more as an API exploration

00:33:07.696 --> 00:33:13.876
and that any great ideas that come out of
it will be a fresh exploration and then

00:33:14.656 --> 00:33:19.696
maybe validate some ideas that get brought
into React or view or other big tools.

00:33:19.786 --> 00:33:22.756
But yeah, I, I could be
wrong, could be, could be more

00:33:23.086 --> 00:33:24.496
independently successful than that.

00:33:25.006 --> 00:33:28.216
They, they did stress in the
video that I watched, that this

00:33:28.216 --> 00:33:29.956
is all like prototype phase.

00:33:29.986 --> 00:33:33.976
So they, like right now apparently
there's splitting it all up into

00:33:33.976 --> 00:33:35.176
a bunch of different packages.

00:33:35.176 --> 00:33:39.136
They can iterate independently and
explore a bunch of different things.

00:33:39.136 --> 00:33:43.231
But the, the final intended
usage would be from one package,

00:33:43.231 --> 00:33:44.881
not from 20 different packages.

00:33:45.361 --> 00:33:48.361
Just to throw that out there
as a a thing that will change.

00:33:48.841 --> 00:33:49.861
Yeah, I don't know.

00:33:49.921 --> 00:33:50.371
We'll see.

00:33:50.881 --> 00:33:51.241
We'll see.

00:33:51.451 --> 00:33:54.331
I think the component model is just
gonna be really hard to disrupt.

00:33:54.421 --> 00:34:00.001
One, one thing I did see in the video of
Ryan Florence talking about just talking

00:34:00.001 --> 00:34:04.351
while he was demoing, he like compared
and contrasted with like, here's how we

00:34:04.351 --> 00:34:08.251
do state changes and you just call the
dispatch function instead of set state.

00:34:08.551 --> 00:34:10.891
And I was like, I dunno,
you can do that in React.

00:34:10.891 --> 00:34:14.701
Like they've been encouraging people to
do that for years, for like six years

00:34:15.001 --> 00:34:18.991
basically Ever since hooks came out and
you could do a state reducer, they were

00:34:18.991 --> 00:34:24.211
like, please, except for trivial uses
of state, all of your state should be in

00:34:24.211 --> 00:34:25.801
a reducer and you should use dispatch.

00:34:25.801 --> 00:34:26.461
Not set state.

00:34:26.971 --> 00:34:30.271
So just like calling that out as a
point of comparison, like React has been

00:34:30.271 --> 00:34:31.951
trying to do that for a long time too.

00:34:31.951 --> 00:34:34.921
It's just nobody actually does, I
dunno, just caught my attention.

00:34:35.431 --> 00:34:37.981
Mark: Well least we have an actual
code to critique now and argue

00:34:37.981 --> 00:34:39.661
about instead of the vague teasing.

00:34:40.111 --> 00:34:41.311
True facts.

00:34:41.641 --> 00:34:44.011
Carl: I will happily continue
reading code and critiquing.

00:34:44.551 --> 00:34:48.001
Speaking of which , I love this project.

00:34:48.031 --> 00:34:50.881
I have thought about doing this
so many different times and I

00:34:50.881 --> 00:34:52.171
never have because it's hard.

00:34:52.471 --> 00:34:57.631
Somebody built the same app 10 times
in a variety of different frameworks

00:34:57.631 --> 00:35:04.141
and tools and benchmarked them and
compared and contrasted their performance

00:35:04.141 --> 00:35:05.371
in a bunch of different metrics.

00:35:05.431 --> 00:35:10.141
It seemed like they focused pretty heavily
on like bundle size to me, very wordy.

00:35:10.141 --> 00:35:12.361
I, I will say I got a
little bit lost in the

00:35:12.361 --> 00:35:12.661
Mark: instruction.

00:35:12.661 --> 00:35:17.371
Very wordy and very, also, a lot of the
article was very clearly AI generated.

00:35:17.371 --> 00:35:20.371
I saw some comments from the author
saying he had written pieces of it in

00:35:20.371 --> 00:35:22.411
sections and used AI to help with it.

00:35:22.651 --> 00:35:25.861
So like there, there was clearly
human involvement in it, but the,

00:35:25.981 --> 00:35:29.701
the AI generation of the article
itself was a critique point.

00:35:30.271 --> 00:35:30.451
Carl: Yeah.

00:35:30.451 --> 00:35:33.151
Just like as I'm scrolling, it's
got so many paragraphs in a row

00:35:33.151 --> 00:35:34.801
that are all like identically long.

00:35:35.281 --> 00:35:36.841
Just a little bit of a wall of text.

00:35:36.841 --> 00:35:38.341
I definitely skimmed this pretty hard.

00:35:38.611 --> 00:35:42.511
All that aside, like I just
love the idea of doing the exact

00:35:42.511 --> 00:35:44.071
same thing with the exact same.

00:35:44.071 --> 00:35:46.861
Like, well, I don't know that they
use the same test suite, but that,

00:35:46.861 --> 00:35:48.001
that was always my idea is build.

00:35:48.031 --> 00:35:52.651
You build an end-to-end test suite and
then you get a passing app for that test

00:35:52.651 --> 00:35:54.121
suite in a bunch of different tools.

00:35:54.641 --> 00:35:57.511
I meant to do more of a deep
code review on a couple of

00:35:57.511 --> 00:35:59.071
the different implementations.

00:35:59.311 --> 00:36:03.421
It's a CanBan board, it's, you
know, a Trello clone type project

00:36:03.421 --> 00:36:06.001
where you're doing task management
with cards and drag and drop.

00:36:06.151 --> 00:36:10.111
I guess it, it's a great and a
parable comparison because drag

00:36:10.111 --> 00:36:12.601
and drop is really hard to do and
so it's very frequently something

00:36:12.601 --> 00:36:14.491
people try to lean on libraries for.

00:36:15.031 --> 00:36:20.521
So if you are implementing it
yourself, that's kind of cha, that

00:36:20.521 --> 00:36:23.791
makes it a little bit challenging
to use as a point of comparison.

00:36:24.301 --> 00:36:29.941
But the tools that were used here,
he built it analog, which I guess is

00:36:29.941 --> 00:36:31.831
vanilla js is what I'm assuming, or

00:36:31.921 --> 00:36:36.421
Mark: analog is actually a,
a next like tool for Angular.

00:36:36.991 --> 00:36:37.291
Carl: Oh great.

00:36:37.321 --> 00:36:37.621
Okay.

00:36:37.891 --> 00:36:38.131
Okay.

00:36:38.131 --> 00:36:41.251
So you built it an analog,
which is an angular type thing.

00:36:41.701 --> 00:36:45.091
And HTMX, Marco, which I'd never heard of.

00:36:45.301 --> 00:36:46.351
Next.JS, of course.

00:36:46.351 --> 00:36:46.951
Next.

00:36:47.041 --> 00:36:47.461
Sure.

00:36:47.851 --> 00:36:49.871
Qwik City, which is Qwik.

00:36:49.891 --> 00:36:51.931
I've heard of Qwik City
I had not heard of.

00:36:51.931 --> 00:36:53.191
So this is I guess

00:36:53.191 --> 00:36:55.591
Mark: probably another solid
versus solid start type thing.

00:36:55.741 --> 00:36:57.091
Carl: Qwik city to qwik Sure.

00:36:57.571 --> 00:37:02.851
Solid start spelt Kit Tan Stack with
solid and then Tan Stack with React.

00:37:03.451 --> 00:37:07.081
Yeah, one of the first tables, one
of the first actual like points of

00:37:07.081 --> 00:37:11.761
comparison of the output tables is
just on bundle size and how much

00:37:11.761 --> 00:37:14.191
JavaScript was served in order to.

00:37:14.851 --> 00:37:15.931
Get this app running.

00:37:16.261 --> 00:37:22.471
They used Next.JS version 16 as
the baseline and that was about 500

00:37:22.471 --> 00:37:24.241
kilobytes gzipped, which is huge.

00:37:24.241 --> 00:37:25.561
It's big hand stack.

00:37:25.561 --> 00:37:27.541
Start with React.

00:37:27.721 --> 00:37:32.071
Clocked in at about 300 kilobytes
a little bit more with solid

00:37:32.071 --> 00:37:33.571
was a half of that hand stack.

00:37:33.571 --> 00:37:36.601
Start with solid was 150 ish kilobytes.

00:37:36.871 --> 00:37:39.331
The smallest was Marco.

00:37:39.826 --> 00:37:43.906
12. At 12 kilobytes followed
by quick city at 88.

00:37:44.146 --> 00:37:47.506
Oh, I just realized there's
parenthesized compressed.

00:37:47.506 --> 00:37:49.306
I thought I was reading the
compressed and I was not.

00:37:49.816 --> 00:37:53.626
Mark: There's also the board
page versus the homepage sizes.

00:37:53.866 --> 00:37:54.286
Carl: Yeah.

00:37:54.286 --> 00:37:54.616
Okay.

00:37:54.706 --> 00:37:54.976
Alright.

00:37:54.976 --> 00:37:57.076
This is more confusingly
presented than I realized.

00:37:57.466 --> 00:38:00.226
Mark: I think the biggest picture
takeaways, number one, it's worth noting

00:38:00.316 --> 00:38:04.006
that the author of this article previously
put up a post a month or two ago saying

00:38:04.006 --> 00:38:08.566
that React by is the default choice and
it's killing innovation in the ecosystem.

00:38:08.956 --> 00:38:11.116
So that kind of to where
they're coming from.

00:38:11.506 --> 00:38:12.406
But I do think they did.

00:38:12.406 --> 00:38:16.966
They were legitimately trying to do
a real meaningful comparison, even

00:38:16.971 --> 00:38:19.906
if the results were sort of what
they were hoping they would be.

00:38:19.906 --> 00:38:21.706
IE reacted big and bad.

00:38:22.306 --> 00:38:28.576
So yeah, the big takeaways are like React
itself is huge and so any React app is

00:38:28.576 --> 00:38:31.756
going to be very large bundle size wise.

00:38:32.236 --> 00:38:37.186
And look, if we do like Tan Stack
with Solid instead of Tan Stack

00:38:37.186 --> 00:38:38.866
with React, it gets smaller.

00:38:39.256 --> 00:38:45.256
But also if you do these other frameworks,
it gets even better smaller and then it

00:38:45.256 --> 00:38:48.856
kind of ends with a bit of a, another
rant about React is a bad choice.

00:38:49.396 --> 00:38:51.106
Carl: Yeah, I, I will validate that.

00:38:51.316 --> 00:38:55.936
To me it also looked like they really
tried to give React a fair shake here.

00:38:55.936 --> 00:38:58.126
Like, you know, if you wanted to, if
you were wanting to complain about

00:38:58.126 --> 00:39:01.876
bundle size, if React apps, like
there are so many easy ways to bloat

00:39:01.876 --> 00:39:03.586
this up to a couple of megabytes.

00:39:04.096 --> 00:39:08.086
So like the fact that they didn't do
that is indicative enough to me that

00:39:08.086 --> 00:39:09.316
they tried to give this a fair shot.

00:39:10.246 --> 00:39:10.756
It's cool.

00:39:10.756 --> 00:39:11.236
I love this.

00:39:11.236 --> 00:39:13.366
This is a great project, great effort.

00:39:13.756 --> 00:39:17.056
I don't know that, to me, at the
end of the day, this is interesting

00:39:17.056 --> 00:39:21.556
and fascinating and a great point of
comparison, and also like not that

00:39:21.556 --> 00:39:26.026
meaningful because the performance
metrics that you measure here that are

00:39:26.026 --> 00:39:31.366
easily measured by comparing the outputs
of identically functional applications,

00:39:31.876 --> 00:39:38.146
that's really only like maybe a third of
the reason why you would choose to build

00:39:38.146 --> 00:39:41.146
an app with any particular set of tools.

00:39:41.176 --> 00:39:45.316
Like really, if you're starting
a company and hiring engineers

00:39:45.316 --> 00:39:47.266
and doing a greenfield project.

00:39:47.941 --> 00:39:51.811
Like some of the most important
things are how much will this cost?

00:39:52.141 --> 00:39:53.101
Mark: How well is everything?

00:39:53.101 --> 00:39:54.781
How well is everything documented?

00:39:54.781 --> 00:39:57.541
How easily can we spin up
engineers who know these things?

00:39:57.541 --> 00:39:59.551
I mean, the, the ecosystem
argument is a real thing.

00:39:59.911 --> 00:40:03.661
Carl: And like, you know, if it takes
you two months to find a developer,

00:40:03.721 --> 00:40:08.041
you know, a senior developer who
can build your app in Marco, you

00:40:08.041 --> 00:40:09.721
know, you could do that in a week.

00:40:09.841 --> 00:40:10.231
I don't know.

00:40:10.471 --> 00:40:14.131
The hiring for React is much easier
than hiring for some niche tool.

00:40:14.131 --> 00:40:16.891
And I have seen writeups of people
saying like, yeah, we built our

00:40:16.891 --> 00:40:20.281
startup on this niche framework
and we couldn't hire for it.

00:40:20.281 --> 00:40:22.771
And that ended up contributing
to the death of the company.

00:40:23.011 --> 00:40:25.711
So like, you know, these performance
metrics are important, they're really

00:40:25.711 --> 00:40:27.301
useful, it's great to have them.

00:40:27.301 --> 00:40:31.441
So we know where opportunities
to improve are like tying this

00:40:31.441 --> 00:40:33.061
back mark to your Immer work.

00:40:33.061 --> 00:40:36.211
Like if somebody hadn't complained
about performance, you wouldn't

00:40:36.211 --> 00:40:37.351
know that it needed to get better.

00:40:37.351 --> 00:40:37.501
Pretty

00:40:37.501 --> 00:40:37.741
Mark: much.

00:40:37.741 --> 00:40:38.011
Yeah.

00:40:38.281 --> 00:40:41.431
Carl: So this is great and I love it,
but it's also not the end all, be all

00:40:41.431 --> 00:40:44.431
of like decision making for, things.

00:40:44.431 --> 00:40:44.731
Yeah.

00:40:45.271 --> 00:40:48.121
It's also, man, this, it's just so
hard to read because of how long it is.

00:40:48.181 --> 00:40:49.891
I wish they'd stripped
this down a bit more.

00:40:49.951 --> 00:40:53.581
Mo: And if we take like a step back out
of our like web ecosystem bubble for a

00:40:53.581 --> 00:40:59.371
second, like you go to like the backend
world and like enterprise business

00:40:59.671 --> 00:41:04.411
companies or finance or whatever, and like
they employ a lot of developers, right?

00:41:04.411 --> 00:41:07.531
Like thousands, thousands
and thousands of developers.

00:41:07.861 --> 00:41:11.791
And like there's a reason they're
all on Java and .Net is because like

00:41:11.971 --> 00:41:15.091
they can hire for those and it's
pretty easy to build a team around.

00:41:15.091 --> 00:41:16.051
That's the top priority.

00:41:16.051 --> 00:41:20.146
Even like this stuff is quite
minuscule when people are, companies

00:41:20.146 --> 00:41:21.571
are hiring at a large scale.

00:41:21.751 --> 00:41:25.321
And then the second thing, which is
like not accounted for, I think in this

00:41:25.321 --> 00:41:30.001
like approach of looking at like just
the bundle size that's outputted is the

00:41:30.001 --> 00:41:34.711
fact that like your productivity with
the fact that most of the AI tools are

00:41:34.711 --> 00:41:39.901
really like optimized around React is not
something that you should not look at and

00:41:39.901 --> 00:41:41.431
consider when you're choosing something.

00:41:41.821 --> 00:41:45.901
There's so much training data and so
much like tooling around building React

00:41:45.901 --> 00:41:50.941
apps quickly and prototyping React
features or React apps that with AI

00:41:50.941 --> 00:41:54.841
that is just a bit, it feels a bit moot
some of some of these conversations.

00:41:54.841 --> 00:41:55.291
It feels.

00:41:55.351 --> 00:41:58.231
Mark: To be clear, like React
has got itself has gotten

00:41:58.231 --> 00:41:59.371
much bigger over the years.

00:41:59.371 --> 00:42:02.191
In fact, even just 18 to 19
it got notice will be bigger.

00:42:02.761 --> 00:42:05.221
Bigger bundle sizes are not a good thing.

00:42:05.221 --> 00:42:08.341
We are not sitting here saying
Your bundle size does not matter.

00:42:08.671 --> 00:42:12.781
Alex Russell, as much as I disagree
with his communication style is right

00:42:12.841 --> 00:42:16.981
to point to the technical receipts
saying that big bundle sizes are

00:42:16.981 --> 00:42:21.511
bad, but also it's not the only
single metric you should care about.

00:42:21.931 --> 00:42:22.651
Carl: Yeah, right.

00:42:22.741 --> 00:42:23.071
Yep.

00:42:23.191 --> 00:42:24.781
And also, last thing I'll shout out here.

00:42:24.781 --> 00:42:30.391
I think the author of this blog
post also mentions that he tried not

00:42:30.391 --> 00:42:32.341
to pull in too many dependencies.

00:42:32.341 --> 00:42:40.471
So like did not pull in fetch wrappers
or data fetch tools like React Query and.

00:42:40.981 --> 00:42:45.091
Axios, the data fetch thing, which
many people still use, I don't know.

00:42:45.451 --> 00:42:49.651
They still have a fair amount of utility
just for things like observability and

00:42:49.651 --> 00:42:51.991
security and various guarantees like that.

00:42:52.291 --> 00:42:57.271
Like Axios itself is 36 kilobytes
ified like 14 compressed.

00:42:57.631 --> 00:42:59.881
React Query is 55 kilobytes.

00:42:59.911 --> 00:43:05.431
I guess to say that the way he did
it is actually better quote unquote

00:43:05.431 --> 00:43:09.871
for React in terms of the bundle size
argument, but it's also not representative

00:43:09.871 --> 00:43:11.311
of how people actually build apps.

00:43:11.371 --> 00:43:16.171
It's a challenge of these types of
articles is that by necessity it has

00:43:16.171 --> 00:43:20.221
to be the level of scope that a single
developer can execute on their own, and

00:43:20.221 --> 00:43:21.481
that's just not how most apps are built.

00:43:21.511 --> 00:43:23.551
Like most apps are not passion
projects by one person.

00:43:23.551 --> 00:43:24.241
So yeah.

00:43:24.721 --> 00:43:25.261
Super cool.

00:43:25.261 --> 00:43:26.251
Love this post.

00:43:26.911 --> 00:43:29.851
It's interesting more than
it is authoritative, I think.

00:43:30.361 --> 00:43:30.931
Mark: Good way to put it.

00:43:31.141 --> 00:43:32.921
Mo, tell us about Solito.

00:43:33.501 --> 00:43:34.831
Mo: Yes, Solito.

00:43:35.101 --> 00:43:36.871
So go back a few months.

00:43:36.871 --> 00:43:40.001
You'll remember that we said
Fernando Rojo joined Vercel.

00:43:40.321 --> 00:43:42.631
And he joined as the head
of mobile firm Vercel.

00:43:43.081 --> 00:43:46.851
This was significant because he's the
author of this library called Solito

00:43:47.161 --> 00:43:49.171
and a few other libraries like Ziga.

00:43:49.471 --> 00:43:52.801
So he's really, for the last
few years, has been focused on.

00:43:53.341 --> 00:43:56.911
Using React native on the web as
well, especially with Next.JS.

00:43:57.301 --> 00:43:59.461
So he built his own startup
in that sort of tech stack.

00:43:59.821 --> 00:44:03.721
It is from experience and having built
with this tech stack quite a lot,

00:44:03.991 --> 00:44:09.331
it's a challenging approach because
you are always balancing oversharing

00:44:09.331 --> 00:44:14.461
between your native components and
your React native code and the web

00:44:14.461 --> 00:44:16.111
functionality that you import in.

00:44:16.111 --> 00:44:20.281
And oftentimes that comes at a
detriment of performance or ux,

00:44:20.581 --> 00:44:22.321
depending on if you do it right.

00:44:22.651 --> 00:44:27.241
And the more that you share, the
more chance there is that you're

00:44:27.241 --> 00:44:29.461
not, you're sharing something
that you probably shouldn't share.

00:44:29.971 --> 00:44:33.661
And so there's a lot of libraries
in the secret system, but Solito is

00:44:33.661 --> 00:44:37.411
probably one of the key ones where
it lets you share navigation across

00:44:37.411 --> 00:44:39.061
Next.JS and React native apps.

00:44:39.421 --> 00:44:42.451
Now, we've talked a bit
about Toledo in the past.

00:44:42.691 --> 00:44:46.711
One of the big limitations that
any library in this space has is

00:44:46.711 --> 00:44:49.591
that it relies on React Native
Web Now, React native web was

00:44:49.591 --> 00:44:50.941
made several, several years ago.

00:44:50.941 --> 00:44:52.231
I think it was back in 2015.

00:44:52.756 --> 00:44:55.036
And it was made by Nicholas Gallagher.

00:44:55.036 --> 00:44:58.336
Now, he also did a talk at React
Conf, which I would recommend

00:44:58.336 --> 00:45:00.406
you watch about React strict dom.

00:45:00.646 --> 00:45:04.126
But the key thing with React Native
Web is that it's not really receiving

00:45:04.126 --> 00:45:07.366
as much love because Nicholas is
working more on React strict dom, which

00:45:07.366 --> 00:45:11.506
is sort of like the future path for
sharing code across the web and mobile.

00:45:11.986 --> 00:45:15.646
And so React native web is, is a little
bit bloated, and what that means is

00:45:15.646 --> 00:45:19.006
that any library that you really use,
especially your, something like your

00:45:19.006 --> 00:45:23.326
navigation and routing library will import
in large portions of React Native Web,

00:45:23.326 --> 00:45:25.036
even if you're not using all of the APIs.

00:45:25.396 --> 00:45:28.246
And so that means that your
bundle size goes through the roof.

00:45:28.696 --> 00:45:33.586
And what the Vercel team slash Fernando
Roho have now been able to do is actually

00:45:33.586 --> 00:45:38.836
remove React Native Web as a dependency
from from Solito, which is pretty massive.

00:45:39.196 --> 00:45:43.936
It sets us up in a foundation where
you can effectively get ready for React

00:45:43.936 --> 00:45:48.676
strict dom adoption more easily in the
long run, but also means that if you

00:45:49.066 --> 00:45:53.686
pick and choose your libraries well, when
you're building a UniVercel app and you

00:45:53.686 --> 00:45:58.486
really think about what you're using on
the web platforms, you can really start

00:45:58.486 --> 00:45:59.986
to tackle that bundle size problem.

00:46:00.586 --> 00:46:03.616
It doesn't help if you're using libraries
like let's say Reanimated, which has a

00:46:03.616 --> 00:46:05.326
pretty heavy reliance on React Native web.

00:46:05.851 --> 00:46:09.301
But if you're going really vanilla
and you're very careful, it means that

00:46:09.301 --> 00:46:14.041
you can actually achieve much better
performance on the web by using this new

00:46:14.041 --> 00:46:15.961
version of Solito, which is very exciting.

00:46:16.321 --> 00:46:19.711
So yeah, if you're already using
Solito, give it a look and if you're

00:46:19.711 --> 00:46:22.501
thinking of building a uniVercel
app, it's a really good candidate if

00:46:22.501 --> 00:46:25.441
you wanna build a highly performant
web variant of your application.

00:46:25.711 --> 00:46:26.251
Carl: I love that.

00:46:26.311 --> 00:46:29.461
It definitely makes a lot of
sense to start moving away from

00:46:29.461 --> 00:46:32.971
React Native Web, given that we've
compared and contrasted React Native

00:46:32.971 --> 00:46:35.011
Web with like React strict dom.

00:46:35.141 --> 00:46:37.911
I guess it makes sense to move
away from React native web, 'cause

00:46:37.911 --> 00:46:42.591
the guy who made it is now doing a
different thing in the exact same

00:46:42.591 --> 00:46:44.691
space from a very different angle.

00:46:44.721 --> 00:46:47.601
So yeah, that's a pretty
strong argument for changing.

00:46:49.056 --> 00:46:56.376
Mark: Okay, the last major topic
for the day next 16 and directives.

00:46:56.616 --> 00:46:58.506
So next 16 came out.

00:46:58.956 --> 00:47:03.606
The headline feature is they now have
what they're calling cash components.

00:47:04.146 --> 00:47:08.256
This is the, I don't know, second,
third, fourth iteration on how

00:47:08.256 --> 00:47:11.766
to do caching in next, across
the last couple major versions.

00:47:12.276 --> 00:47:14.976
I'm not gonna pretend that I
understand what, how this works.

00:47:15.336 --> 00:47:19.056
No one does, but thing
is that they introduced.

00:47:19.351 --> 00:47:21.391
Another new directive.

00:47:21.451 --> 00:47:25.981
Now to recap a directive is these little
strings that you just put in your code.

00:47:26.521 --> 00:47:33.721
Originally we had use strict back in
the ES 2015 days and then React server

00:47:33.721 --> 00:47:40.341
components introduced, use server and
use client, and now we have 'use cache'.

00:47:40.681 --> 00:47:44.851
And the idea is that by slapping this
directive on certain components, that

00:47:44.851 --> 00:47:48.871
tells the next bundler and compiler
that, Hey, this is the output of this

00:47:48.871 --> 00:47:50.461
component is supposed to be cached.

00:47:50.491 --> 00:47:51.631
I don't understand the details.

00:47:51.631 --> 00:47:53.821
From there, go read
the documentation long.

00:47:53.821 --> 00:48:00.301
With that, they also announced a new
long-lived workflow product, kind of

00:48:00.301 --> 00:48:02.636
similar to what the temporal company.

00:48:03.311 --> 00:48:07.661
Has built where you can have a function,
for example, that implements a billing

00:48:07.661 --> 00:48:13.931
workflow by sweeping for 30 days and
you've written what looks like one

00:48:13.931 --> 00:48:18.851
function, but under the hood it's actually
like saving its status to a database and

00:48:18.851 --> 00:48:22.961
then a time job wakes it up and continues
executing the code, that sort of thing.

00:48:23.591 --> 00:48:30.521
And I believe they opted to implement
this also with a use workflow directive

00:48:30.521 --> 00:48:32.441
and like a use step directive.

00:48:33.271 --> 00:48:37.411
And I think there may have even
been one or two others related to

00:48:37.411 --> 00:48:42.781
variations on caching, like use
Cache, remote, something like that.

00:48:43.261 --> 00:48:46.891
And meanwhile, we've also got the
React compiler has opted to use

00:48:46.891 --> 00:48:48.691
directives for a couple things.

00:48:48.691 --> 00:48:52.321
So there's a use no memo directive.

00:48:52.321 --> 00:48:57.571
If you want to tell the compiler, don't
try to auto optimize this component.

00:48:58.111 --> 00:49:03.301
And so all of a sudden we've gone from
the JavaScript language specifying.

00:49:03.681 --> 00:49:04.881
One directive.

00:49:05.241 --> 00:49:10.821
There was also the unofficial,
oh, was it use a SM directive that

00:49:10.821 --> 00:49:15.951
was part of a SM js, the precursor
to web assembly, but like one

00:49:15.951 --> 00:49:17.931
official directive in the language.

00:49:18.411 --> 00:49:22.341
And now we have a couple for bundlers,
and now we have more for workflows and

00:49:22.341 --> 00:49:23.961
the compiler and all these other things.

00:49:24.531 --> 00:49:28.131
And so the Twitter discourse
over the last couple weeks has

00:49:28.131 --> 00:49:31.281
been our directives, good or bad.

00:49:31.341 --> 00:49:34.911
And they're so confusing and
they are changing the language.

00:49:34.911 --> 00:49:39.951
And you have all this bundler
defined behavior that is not

00:49:39.951 --> 00:49:41.151
part of the language spec.

00:49:41.661 --> 00:49:45.321
And so Tanner Linsley, again, creator
of all the different Tan Stack

00:49:45.321 --> 00:49:50.541
libraries, put out a blog post where
he expressed his opinion that he does

00:49:50.541 --> 00:49:53.151
not think directives are a good idea.

00:49:53.496 --> 00:49:58.386
Because they are unofficial, because
they're not standardized, because make

00:49:58.386 --> 00:50:03.456
it not clear what the actual intended
behavior ought to be, as opposed to

00:50:03.456 --> 00:50:08.856
like explicitly importing a function
that says, turn this into a client

00:50:08.856 --> 00:50:11.196
server function or something like that.

00:50:11.676 --> 00:50:16.206
So there there's been a lot
of arguing about directives

00:50:16.236 --> 00:50:18.366
and are they understandable?

00:50:18.366 --> 00:50:19.386
Are they good or bad?

00:50:19.386 --> 00:50:20.466
Are they too much magic?

00:50:20.916 --> 00:50:22.176
So that's been happening.

00:50:22.536 --> 00:50:23.106
Carl: I'll say it.

00:50:23.166 --> 00:50:23.736
They're bad.

00:50:23.826 --> 00:50:24.576
It's too much magic.

00:50:24.576 --> 00:50:25.146
I hate it.

00:50:25.231 --> 00:50:25.926
I'm not a fan.

00:50:26.461 --> 00:50:27.751
Mark: I understand the thought process.

00:50:27.776 --> 00:50:29.371
I, I can't say I'm thrilled.

00:50:29.701 --> 00:50:33.241
And so on that note, two article
articles that are related enough

00:50:33.241 --> 00:50:34.561
to throw them into this section.

00:50:34.891 --> 00:50:41.341
I've seen lots of different article
articles upset at Next or critiquing next.

00:50:41.341 --> 00:50:45.451
Most of them are frankly very badly
written, but I saw one come out last

00:50:45.451 --> 00:50:49.651
week that I thought was very well written
and focused strictly on the technical

00:50:49.831 --> 00:50:52.231
pros and cons of using the App Router.

00:50:52.651 --> 00:50:56.161
The title is Clickbait, everyone
Hates Next, but the article itself

00:50:56.161 --> 00:50:57.541
is actually very well written.

00:50:57.541 --> 00:51:01.531
It discusses technical aspects of
using Next, some of the problems his

00:51:01.531 --> 00:51:06.421
team went in, ran into, and how and
why they ended up migrating from the

00:51:06.421 --> 00:51:08.671
App Router over to 10 Stack Start.

00:51:08.911 --> 00:51:13.051
And then Nadia Vic, who has done a
bunch of very excellent articles on

00:51:13.051 --> 00:51:18.871
React rendering behavior, put together
a very data-driven look into do server

00:51:18.871 --> 00:51:23.761
components actually help with things
like First Contentual Paint and various

00:51:23.761 --> 00:51:25.471
other White House style metrics.

00:51:26.066 --> 00:51:27.266
So very worth reading.

00:51:27.836 --> 00:51:31.796
Carl: As I'm trying to think about how
you might solve problems of caching

00:51:31.856 --> 00:51:35.216
and runtime things without directives.

00:51:35.696 --> 00:51:38.366
And I'm thinking about, you know,
my experiences using like CloudFlare

00:51:38.366 --> 00:51:44.996
workers or other runtimes where it's
not a traditional process scope.

00:51:45.356 --> 00:51:48.926
And I don't know, I guess like it
is a really challenging question

00:51:48.926 --> 00:51:52.496
of like, how do you signal to a
developer that the file they're editing

00:51:52.736 --> 00:51:55.856
runs in a certain type of context?

00:51:56.336 --> 00:51:59.516
And I guess I understand why
directives are an appealing thing to

00:51:59.516 --> 00:52:04.886
reach for, but man, just the state
we're in right now is really a lot.

00:52:05.366 --> 00:52:09.676
I found the Next.JS docs page with
directives and it lists 'use cache',

00:52:09.896 --> 00:52:13.846
'use client', 'use server', and then
two sub variants of 'use cache'.

00:52:14.396 --> 00:52:19.706
And that's not all of 'em that,
so there's missing ones here and.

00:52:20.426 --> 00:52:20.786
I don't know.

00:52:20.786 --> 00:52:26.306
When you start getting into like
many different contexts, just naming

00:52:26.306 --> 00:52:30.266
them at the top of the file doesn't
really seem like enough for me.

00:52:30.296 --> 00:52:30.656
I don't know.

00:52:30.656 --> 00:52:35.696
And then like the implication for that
code can import other code that will not

00:52:35.696 --> 00:52:40.016
have it flagged what context it's running
in via a directive at the top of the file.

00:52:40.806 --> 00:52:41.646
And I don't know.

00:52:41.676 --> 00:52:42.426
It's a tough problem.

00:52:42.426 --> 00:52:47.766
It's a weird unanswered question
in the industry, like not even the

00:52:47.766 --> 00:52:49.296
ecosystem, but like the industry.

00:52:49.296 --> 00:52:54.756
How do you flag code that might run on
your browser, a real server, serverless

00:52:54.756 --> 00:52:57.126
environment, and yeah, I don't know.

00:52:57.816 --> 00:52:58.506
It's a challenge.

00:52:58.986 --> 00:53:02.376
Mark: I think it really does speak
to the overhead and mental complexity

00:53:02.646 --> 00:53:04.266
of trying to juggle all these things.

00:53:04.566 --> 00:53:09.906
We said earlier that React 19 has, 18,
19 have introduced a whole lot of things

00:53:09.906 --> 00:53:15.036
like transitions and other pieces to try
to let you write better user experiences.

00:53:15.546 --> 00:53:19.476
But now you're having to juggle in your
head like, here's the current version

00:53:19.476 --> 00:53:24.516
of my app in its display state versus
a work in progress rendered version

00:53:24.906 --> 00:53:27.996
versus a future output rendered version.

00:53:28.536 --> 00:53:33.111
On the server side we're having to deal
with, this is server code, this is client

00:53:33.111 --> 00:53:36.231
code, sometimes they're mixed together
in the same file, sometimes they're

00:53:36.231 --> 00:53:37.941
mixed together in the same component.

00:53:38.241 --> 00:53:39.351
Which code is running?

00:53:39.351 --> 00:53:44.181
In which context do I have to worry
about accidentally leaking security

00:53:44.181 --> 00:53:45.681
tokens or something like that.

00:53:46.071 --> 00:53:50.991
We're building tools to solve real
problems, but there's more and more

00:53:50.991 --> 00:53:53.271
to juggle in your head as you go.

00:53:53.661 --> 00:53:57.621
Carl: Well, I'm gonna plug effect one more
time because I saw it come up in the chat.

00:53:57.951 --> 00:53:58.521
Oh, man.

00:53:58.551 --> 00:54:04.611
It just like talking about different
ways of signaling facts about the code.

00:54:04.611 --> 00:54:06.651
The code you're writing
has certain dependencies.

00:54:06.651 --> 00:54:08.841
Certain dependencies is too loaded.

00:54:08.841 --> 00:54:11.661
That's, that carries too much context
with it, but the code you write

00:54:11.661 --> 00:54:16.446
has a certain amount of assumption
baked into it about what will be

00:54:16.446 --> 00:54:20.106
available and what it can rely on.

00:54:20.466 --> 00:54:23.286
The thing I love about a fact is
that it makes that more explicit

00:54:23.316 --> 00:54:26.196
and brings it into the type system.

00:54:26.706 --> 00:54:32.346
So I think the challenge right now is
that we are missing a like platform

00:54:32.346 --> 00:54:38.346
and language level abstraction
to express information like this.

00:54:38.916 --> 00:54:41.886
And yeah, I don't think we're
gonna get it anytime soon.

00:54:41.976 --> 00:54:46.536
And I think these explorations will
lead to something like that and

00:54:46.536 --> 00:54:47.646
hopefully converge into something.

00:54:47.646 --> 00:54:51.426
But I think this is gonna be like
a real state-of-the-art problem

00:54:51.426 --> 00:54:55.176
for a couple of years and still,
which I hate, but it'll get better.

00:54:56.136 --> 00:54:57.966
Mark: Alright, moving on
to the lightning round.

00:54:58.386 --> 00:55:03.036
In addition to React Con and Remix
Jam, we also had Vite Conf and the V

00:55:03.036 --> 00:55:06.966
team gave a bunch of updates on all the
different tools they've been working on.

00:55:07.356 --> 00:55:12.366
Some of the highlights to me were
that OX LT now supports ES lint and JS

00:55:12.366 --> 00:55:19.266
plugins via some really awesome tricks
for interop between js and rust without

00:55:19.296 --> 00:55:21.456
the the cost of serial serialization.

00:55:21.996 --> 00:55:28.116
They announced a combined tool chain
called v plus, which basically pulls

00:55:28.236 --> 00:55:33.696
all the different tools, VIOX lint, OX
format, Vitest, everything else together.

00:55:34.056 --> 00:55:37.656
That'll be their enterprise
sales targeted tool set.

00:55:37.986 --> 00:55:41.436
And then Vitest four is out
with browser mode support.

00:55:42.006 --> 00:55:45.606
You basically just put a flag in
your Vitest config and suddenly

00:55:45.606 --> 00:55:48.936
your tests are running in a real
browser instead of a node plus js.

00:55:49.446 --> 00:55:55.866
Last week, AWS east went down and the
internet died and they put out the

00:55:55.866 --> 00:56:02.736
postmortem and it was DNS apparently
they, their internal DNS system for

00:56:02.736 --> 00:56:08.046
dynamo DB had like three different
instances of the DNS updater running

00:56:08.556 --> 00:56:13.326
and one of them got stuck and was taking
a long time to complete, and the other

00:56:13.326 --> 00:56:17.766
one came along and updated and then
said, well, these, some of these plans

00:56:17.766 --> 00:56:19.296
look out of date, let's delete them.

00:56:19.776 --> 00:56:23.766
And next thing you know, DNS
goes down, dynamo DB goes down

00:56:23.766 --> 00:56:26.076
and the internet goes down.

00:56:26.586 --> 00:56:28.056
So, oops.

00:56:28.386 --> 00:56:31.326
Mo: It's funny that the, uh,
internet is backed by Dynamo db.

00:56:31.506 --> 00:56:34.266
Mark: A lot of people like
us East One is the default.

00:56:34.356 --> 00:56:37.116
A lot of people have tried to get
away from US East one, but when a lot

00:56:37.116 --> 00:56:39.276
of Amazon's own stuff depends on US.

00:56:39.276 --> 00:56:39.906
East one.

00:56:40.236 --> 00:56:40.536
Yep.

00:56:40.596 --> 00:56:40.986
You all

00:56:40.986 --> 00:56:43.416
Mo: of your certificates can
only be issued in US East one,

00:56:43.416 --> 00:56:45.006
so that doesn't really help much.

00:56:45.336 --> 00:56:50.106
Side note, if you end up working in a
consultancy one day, just hope nothing

00:56:50.106 --> 00:56:53.406
like this happens because the morning
of was fascinating reaching out and

00:56:53.406 --> 00:56:56.976
getting reached out to by a bunch of
clients being like, my site is down.

00:56:57.486 --> 00:57:00.966
And then having to figure out what's
going wrong, which is US East one on AWS.

00:57:01.056 --> 00:57:02.226
So it was a fun Monday,

00:57:02.856 --> 00:57:05.916
Carl: but at least the uh, at the
end of it was a vendor is out.

00:57:06.066 --> 00:57:07.056
This is not our fault.

00:57:07.986 --> 00:57:09.606
Mo: At least it was that, which was great.

00:57:09.846 --> 00:57:10.266
Cool.

00:57:10.266 --> 00:57:10.986
Moving on.

00:57:10.986 --> 00:57:14.406
So a couple of React native
lightning route items.

00:57:14.436 --> 00:57:18.516
Firstly ra, which is really cool because
we've talked a little bit about live

00:57:18.516 --> 00:57:22.086
activities on iOS and iOS extensions,
all of the little widgets and stuff

00:57:22.086 --> 00:57:24.126
that you can now use on your iPhone.

00:57:24.306 --> 00:57:28.476
And you were able to use iOS
extensions within a React native app.

00:57:28.626 --> 00:57:30.846
But the challenge was you had
to write SWIFT code to be able

00:57:30.846 --> 00:57:32.016
to actually implement those.

00:57:32.136 --> 00:57:37.866
And so a independent developer named
S has been working on building an MPM

00:57:37.866 --> 00:57:42.246
package that allows you to ship these
custom widgets and extensions without

00:57:42.246 --> 00:57:47.496
needing to use Swift X code or extra js,
which is so cool because he's basically

00:57:47.496 --> 00:57:54.756
had to like write a translation layer
or a render that takes React UI code.

00:57:55.311 --> 00:58:00.921
And converted to Swift UI code,
which is not trivial because many

00:58:00.921 --> 00:58:02.811
have tried before him and failed.

00:58:03.081 --> 00:58:06.441
So this is a really cool project
and like it's one of those things

00:58:06.441 --> 00:58:07.911
that's like kind of mind blowing.

00:58:08.151 --> 00:58:09.951
So kudos to him for making this.

00:58:10.371 --> 00:58:13.341
Secondly, and I thought this was
an interesting article to link to.

00:58:13.491 --> 00:58:20.001
On the expo blog, they publish an article
about building fully native apps with EAS.

00:58:20.031 --> 00:58:22.491
So EAS is expo's application services.

00:58:22.791 --> 00:58:28.971
Typically, this is being used to build
React native apps that are usually

00:58:28.971 --> 00:58:33.741
running on Expo, but actually a lesser
known fact, and one that we've actually

00:58:33.741 --> 00:58:37.131
used on some of our apps is that you
don't need to be on Expo and you don't

00:58:37.131 --> 00:58:38.511
even need to be on a React native app.

00:58:39.081 --> 00:58:43.971
And so EAS is really great and it's become
super mature and it's a really just good

00:58:43.971 --> 00:58:45.531
build tool for building mobile apps.

00:58:45.861 --> 00:58:49.251
And so people have started to use it
in the wider mobile community rather

00:58:49.251 --> 00:58:51.831
than it just being a React native
thing, which is quite cool to see.

00:58:52.311 --> 00:58:57.801
And lastly, this was something that
Tzveton from the Hermes team in Meta

00:58:57.801 --> 00:59:00.261
actually, uh, published a week or so ago.

00:59:00.561 --> 00:59:05.241
And this was actually something he linked
me on a DM because we were chatting about

00:59:05.241 --> 00:59:08.541
interesting things that could be talked
about at a conference by a Hermes team.

00:59:08.961 --> 00:59:10.371
And this was quite cool to see.

00:59:10.371 --> 00:59:16.581
So for those who don't know, Imgui is like
a very light UI layer that is powering a

00:59:16.581 --> 00:59:18.201
lot of sort of debugging for video games.

00:59:18.786 --> 00:59:21.516
And it's used in a bunch of other places,
but like the key thing is that it's just

00:59:21.516 --> 00:59:23.976
like a very, very lightweight UI layer.

00:59:24.276 --> 00:59:29.736
And so he made a puck of basically
using React and then rendering

00:59:29.736 --> 00:59:31.416
it on Imgui, which is quite cool.

00:59:31.806 --> 00:59:33.846
And it runs obviously like fully natively.

00:59:33.846 --> 00:59:36.186
It's fully running on c plus plus.

00:59:36.276 --> 00:59:41.706
And all it really needed was some typed
JavaScript and it's basically just

00:59:41.706 --> 00:59:43.566
React really, which is quite cool.

00:59:43.836 --> 00:59:47.286
So yeah, it's just a little cool
fun POC, but it shows the power

00:59:47.286 --> 00:59:51.696
of using React and how it can be
applied to different contexts, which

00:59:51.696 --> 00:59:52.896
I thought was quite cool to include.

00:59:53.301 --> 00:59:57.681
Mark: Okay, Lodash has powered much
of the JavaScript ecosystem for years.

00:59:57.771 --> 01:00:00.711
Those of us who have been around for
a while, remember its predecessor,

01:00:02.031 --> 01:00:05.481
but low, has also been relatively
unmaintained for a while.

01:00:05.811 --> 01:00:09.171
The author John David Dalton, said
there was going to be a low dash

01:00:09.171 --> 01:00:13.941
version five, and then that never really
happened, and so some announcements

01:00:13.941 --> 01:00:15.231
came out in the last week or two.

01:00:15.261 --> 01:00:21.141
That low dash is being taken over by a
new maintenance foundation, and they're

01:00:21.141 --> 01:00:25.731
going to be doing work to update the ci,
put out some new maintenance releases,

01:00:26.121 --> 01:00:31.041
and then apparently when low dash V five
happens, it'll be more about stripping

01:00:31.041 --> 01:00:35.991
out a lot of the internals that tried
to polyfill platform behavior and

01:00:35.991 --> 01:00:40.071
try and make it lighter and make use
of platform built-ins at this point.

01:00:40.491 --> 01:00:43.581
So Lodash is still around, it
ain't going anywhere, and good

01:00:43.581 --> 01:00:44.871
to see it being maintained.

01:00:45.381 --> 01:00:50.211
And then there was a really good post
unrelated to React, but cool on building

01:00:50.211 --> 01:00:56.631
your own key value database system that
walks through a whole bunch of pieces on

01:00:56.661 --> 01:01:01.071
what a key value database actually has to
track and how the internals would work.

01:01:01.071 --> 01:01:03.801
And I believe it's actually
pretty interactive, which is cool.

01:01:04.101 --> 01:01:07.371
Carl: This build your own database
post, I love, this is so good.

01:01:07.371 --> 01:01:10.701
I love when people rebuild
foundational building blocks.

01:01:11.151 --> 01:01:14.001
And this is also something I've thought
about a little bit because he talks

01:01:14.001 --> 01:01:17.361
about in a file, you know, if you need
to store something, put it in a file.

01:01:18.021 --> 01:01:21.531
And this is something I've thought
about a little bit because I have been

01:01:21.531 --> 01:01:25.521
using SQL Light pretty extensively in
my own work the last couple of years.

01:01:26.001 --> 01:01:27.951
And at the end of the day,
sequel light is a file.

01:01:28.161 --> 01:01:31.791
So like when I realized
that like most of the time.

01:01:32.466 --> 01:01:35.616
If I want to store something in a
file, like I should just use sql,

01:01:35.886 --> 01:01:38.346
you put something in a file and then
the file gets too big and you need

01:01:38.346 --> 01:01:42.096
to optimize it, and you need a better
way to access it and like, oh, maybe

01:01:42.096 --> 01:01:44.706
I could use a more descriptive query
language to get things out of it.

01:01:44.706 --> 01:01:50.376
And like the end result is that you
will recreate a shittier less performant

01:01:50.616 --> 01:01:53.406
version of SQLite that doesn't use sequel.

01:01:54.006 --> 01:01:54.846
And so, I don't know.

01:01:54.846 --> 01:01:58.206
I just like reading this that
was very strongly on my mind and

01:01:58.626 --> 01:02:00.936
everyone should do SQLite if they
start putting things in a file.

01:02:00.966 --> 01:02:01.896
'cause it's just a file.

01:02:02.256 --> 01:02:02.706
It's cool.

01:02:02.736 --> 01:02:03.156
I like it.

01:02:03.606 --> 01:02:07.866
Mark: The SQL Light website even has
a page that says why, why you should

01:02:07.866 --> 01:02:14.076
consider just using SQL L as your
app's file format rather than inventing

01:02:14.076 --> 01:02:16.356
another new binary format from scratch.

01:02:16.566 --> 01:02:17.196
Carl: A hundred percent.

01:02:17.196 --> 01:02:20.766
If you start right, if you start
thinking I should put this in a binary

01:02:20.766 --> 01:02:22.776
format on disc, like no, stop it.

01:02:22.986 --> 01:02:23.646
Use SQLite.

01:02:23.856 --> 01:02:24.306
It's great.

01:02:24.816 --> 01:02:25.086
Mark: Alright.

01:02:25.146 --> 01:02:28.956
Jared Palmer, the creator of
the Formik Library, has had

01:02:28.956 --> 01:02:30.786
been at V at Vercel for years.

01:02:30.876 --> 01:02:35.026
He worked on turbo repo, v0.

01:02:35.046 --> 01:02:37.896
And he announced just a month or
two ago he was leaving Vercel.

01:02:38.166 --> 01:02:44.856
He has then announced that he has joined
Microsoft as a senior VP at GitHub.

01:02:45.576 --> 01:02:50.376
And the first thing he did was post
on Twitter saying, how can we make

01:02:50.376 --> 01:02:53.166
the GitHub PR experience better?

01:02:53.676 --> 01:02:57.996
And he got like eight or 900
replies, and he was pretty actively

01:02:57.996 --> 01:02:58.986
engaging with a lot of 'em.

01:02:58.986 --> 01:03:03.036
A lot of them were people asking for
things like Stacked Diff support, so

01:03:03.036 --> 01:03:06.636
you could have multiple PR branches
that depend on each other and be

01:03:06.636 --> 01:03:08.406
able to automatically update them.

01:03:08.961 --> 01:03:12.681
He actually came back even just
a couple days later and gave some

01:03:12.681 --> 01:03:17.631
technical details that he had found
after internal discussions on here were

01:03:17.631 --> 01:03:23.391
some previous prototypes of stacked
diffs at GitHub and how, like how far

01:03:23.391 --> 01:03:25.431
they got and what the blockers were.

01:03:25.911 --> 01:03:30.951
So I have no idea how long it'll take
to roll out any of this stuff, but like

01:03:30.951 --> 01:03:35.811
he seems pretty serious about trying
to improve the PR experience, whether

01:03:35.811 --> 01:03:40.341
it's paper cuts or new functionality
and is trying to look into that stuff.

01:03:40.431 --> 01:03:43.731
So given that we all pretty much
depend on the GitHub PR experience,

01:03:43.731 --> 01:03:45.201
I'm happy to see improvements.

01:03:45.711 --> 01:03:46.071
Carl: Yep.

01:03:46.071 --> 01:03:46.701
Love that.

01:03:46.851 --> 01:03:47.061
Wow.

01:03:47.061 --> 01:03:48.231
This is very jargon heavy.

01:03:48.321 --> 01:03:50.341
Mark: Yeah, I, I know, that's
why I was happy to see it.

01:03:50.751 --> 01:03:51.411
Cool.

01:03:51.891 --> 01:03:53.751
Carl: Sounds like a technical roadmap.

01:03:54.141 --> 01:03:59.061
Mark: Couple other bits, node 25 is out
and so another development line branch

01:03:59.061 --> 01:04:02.541
for node and the biggest thing there
is they've updated the version of V

01:04:02.541 --> 01:04:07.731
eight and that includes those faster js
ON string of FI improvements that we,

01:04:07.761 --> 01:04:09.321
we talked about a couple months ago.

01:04:09.801 --> 01:04:12.951
So given how much everything
depends on JSONs string offi, it's

01:04:12.981 --> 01:04:14.781
nice to see that being sped up.

01:04:15.306 --> 01:04:20.256
And speaking of more optimization work,
I believe Theo put out a benchmark

01:04:20.406 --> 01:04:25.206
where he was comparing CloudFlare
in Vercel in Building Next versus

01:04:25.206 --> 01:04:26.916
Vanilla versus a couple other things.

01:04:27.366 --> 01:04:32.016
And it pointed out places that both
Vercel and CloudFlare were slow and

01:04:32.046 --> 01:04:35.976
CloudFlare jumped on this and they
found a bunch of places in their system.

01:04:36.246 --> 01:04:38.046
Where things could be optimized.

01:04:38.526 --> 01:04:42.246
They did a excellent blog post
detailing some of the improvements.

01:04:42.546 --> 01:04:46.476
They also went in and they looked at next
itself and they found a bunch of places

01:04:46.476 --> 01:04:54.216
where Next is doing like useless request
copying like 1500 or 1700 request streams

01:04:54.666 --> 01:04:56.976
per request or something like that.

01:04:57.276 --> 01:05:01.086
So basically everybody is
getting faster as a result of

01:05:01.086 --> 01:05:01.841
this, which is a good thing.

01:05:02.681 --> 01:05:04.841
Mo: CloudFlare folks are just
doing some great work recently,

01:05:04.931 --> 01:05:07.871
especially with the whole like workers
rebrand as well is really cool.

01:05:07.991 --> 01:05:12.821
Mark: So Interop is an attempt to
get all the different browsers on the

01:05:12.821 --> 01:05:17.051
same page in terms of what features
they're working on, especially around

01:05:17.051 --> 01:05:19.391
compatibility with each other each year.

01:05:19.811 --> 01:05:25.061
And so this year the Firefox folks
put up a rather nifty interactive

01:05:25.061 --> 01:05:29.231
suggestions thing where they list
dozens, like 50 or a hundred different

01:05:29.231 --> 01:05:35.261
potential features or technical areas of
emphasis that they could spend time on.

01:05:35.771 --> 01:05:39.431
And it's got a neat drag and drop
interface where you can basically use that

01:05:39.431 --> 01:05:44.261
as a way to vote for which features do
you want browser manufacturers to work on?

01:05:44.751 --> 01:05:45.171
This year.

01:05:45.801 --> 01:05:46.311
Carl: Love that.

01:05:46.551 --> 01:05:46.761
Yeah.

01:05:46.761 --> 01:05:49.821
They say they're gonna publish
the final selection of proposals

01:05:49.821 --> 01:05:52.341
in February, so I'll, I'll keep
an eye out on that, I guess.

01:05:52.851 --> 01:05:53.181
Cool.

01:05:53.241 --> 01:05:56.691
Chris Chedeau, vjeux, he has
been really prolific in the

01:05:56.691 --> 01:05:58.461
React ecosystem for many years.

01:05:58.461 --> 01:06:02.961
Was really influential in React becoming
open source and was the original

01:06:02.961 --> 01:06:07.971
author of Prettier, which changed my
professional experience significantly.

01:06:08.271 --> 01:06:12.621
He put out a blog post titled The
Birth of Prettier earlier this month.

01:06:12.681 --> 01:06:15.111
I'd spent almost 10 years
since Prettier was released.

01:06:15.111 --> 01:06:16.851
He says, which is wild.

01:06:17.241 --> 01:06:21.261
I like his introduction of this is
the story of how the tabs first spaces

01:06:21.261 --> 01:06:23.796
Holy War ended, and yeah, it did.

01:06:23.931 --> 01:06:24.681
I appreciate that.

01:06:24.711 --> 01:06:28.231
I actually just did a little
DX PR for a code base.

01:06:28.231 --> 01:06:33.301
I maintain to make better use of prettier
because somebody created a plugin to

01:06:33.301 --> 01:06:36.271
sort imports and like, yes, I love that.

01:06:36.271 --> 01:06:39.121
I hate sorting my imports and I hate
when of my imports are not sorted.

01:06:39.601 --> 01:06:43.801
The introduction of automated
formatting into the JavaScript ecosystem

01:06:43.801 --> 01:06:46.351
was, oh, what a, what a blessing.

01:06:46.591 --> 01:06:48.121
Like what hours?

01:06:48.301 --> 01:06:51.781
The years of my life that have
been saved from arguing over

01:06:51.781 --> 01:06:55.741
formatting is just really lovely
and this is a great retrospective.

01:06:55.861 --> 01:06:58.351
Looking into just the whole
process of how it came out.

01:06:58.381 --> 01:07:00.361
Mark: There's some
fascinating details in there.

01:07:00.571 --> 01:07:04.501
Carl: Yeah, like one of the challenges
of this that I remember in the moment a

01:07:04.501 --> 01:07:10.351
little bit, but like if you're gonna start
formatting things, the format needs to

01:07:10.351 --> 01:07:15.141
be something relatively unobjectionable
to the people who are evaluating

01:07:15.141 --> 01:07:16.491
whether they want to use it or not.

01:07:16.551 --> 01:07:23.931
Like, yeah, so, and then figuring
out what options should be exposed,

01:07:23.931 --> 01:07:25.851
what is actually configurable,
because if you make it too

01:07:25.851 --> 01:07:27.921
configurable, then it's not helpful.

01:07:28.371 --> 01:07:35.361
If it's too much manual thing, then
it's not actually consistent enough to

01:07:35.361 --> 01:07:37.371
be valuable at its intended purpose.

01:07:37.371 --> 01:07:40.191
So lots of really interesting
details throughout here.

01:07:40.401 --> 01:07:41.271
Definitely recommend it.

01:07:41.511 --> 01:07:45.741
I always love a great technical white
paper, a writeup of implementation,

01:07:46.131 --> 01:07:48.051
and this is, oh boy, is this that.

01:07:48.051 --> 01:07:48.561
It's great.

01:07:49.011 --> 01:07:51.591
Mark: One of the most interesting
bits I saw was he was talking about

01:07:51.591 --> 01:07:55.401
how they started rolling it out
and like Prettier has some options,

01:07:55.521 --> 01:07:59.001
but they wanted to minimize them
and he wanted everyone to basically

01:07:59.121 --> 01:08:02.001
agree on a single set of options.

01:08:02.451 --> 01:08:05.721
And so he said the strategy I used to
figure out how to make this work was

01:08:05.721 --> 01:08:10.191
lining up incentives so that it took
a ton more work to use a different

01:08:10.191 --> 01:08:12.111
set of options if you wanted to.

01:08:12.801 --> 01:08:16.791
It said Prettier is either in
this, in CI or in your IDE.

01:08:17.091 --> 01:08:20.361
So I made it so that they read
them from different places with a

01:08:20.361 --> 01:08:23.841
different rollout schedule to make
it harder to choose one or the other.

01:08:24.651 --> 01:08:25.521
Carl: Oh, that's incredible.

01:08:25.701 --> 01:08:26.391
That's some good details.

01:08:26.391 --> 01:08:30.801
Reading this a little bit more is it's
got lots of fun non-technical details

01:08:30.831 --> 01:08:34.461
that like they're not the engineering
work, but they are absolutely essential

01:08:34.461 --> 01:08:40.176
for actually making a thing that is
successful and sustainable and thriving.

01:08:40.266 --> 01:08:43.926
Like it also talks about money
and like ongoing maintenance is

01:08:43.926 --> 01:08:45.036
a thing that you have to pay for.

01:08:45.546 --> 01:08:48.336
You don't have to, I guess most open
source does not, but if you don't,

01:08:48.336 --> 01:08:49.866
then it has its own challenges.

01:08:49.866 --> 01:08:54.276
So like not only is this a great technical
writeup, but it's also a great, I don't

01:08:54.276 --> 01:08:55.536
know, like entrepreneurial writeup.

01:08:55.596 --> 01:08:57.876
Mark: How do you do the, the
real work to make stuff happen?

01:08:58.146 --> 01:09:01.716
Carl: People talk about the difference
between like senior and staff

01:09:01.716 --> 01:09:04.746
engineering being, the difference
between junior and senior is how

01:09:04.746 --> 01:09:06.546
much English you're asked to write.

01:09:06.816 --> 01:09:10.086
And the difference between senior and
staff is like how much non-technical

01:09:10.086 --> 01:09:12.306
things you're asked to account for.

01:09:12.636 --> 01:09:16.806
And so this is a phenomenal, I
would say, staff engineer writeup.

01:09:16.806 --> 01:09:21.456
Like, this is how you take an idea and you
make it an industry level impact project.

01:09:21.546 --> 01:09:21.756
Yeah.

01:09:21.876 --> 01:09:22.331
Great Writeup.

01:09:23.061 --> 01:09:25.821
Mark: I can even point to a
couple personal examples of how

01:09:25.851 --> 01:09:28.971
prettier has affected my work
just within the last few days.

01:09:28.971 --> 01:09:34.251
One is that I'm jumping between the
Redux repo, which is two spaces,

01:09:34.251 --> 01:09:36.591
single quotes, no semicolons.

01:09:36.921 --> 01:09:41.811
The Immer repo, which is four spaces,
double quotes, and I can't, and may,

01:09:41.871 --> 01:09:46.731
maybe no single semicolons, Replay.io
repo, which is four spaces, double

01:09:46.731 --> 01:09:51.651
quotes, semicolons, and I don't
think about any of that anymore.

01:09:52.131 --> 01:09:59.511
And then also just yesterday, I was trying
to tweak some of ER's exports and tried

01:09:59.511 --> 01:10:07.326
to put in an export type keyword, which I
was pretty sure was a legit thing except

01:10:07.326 --> 01:10:09.486
that when I hit save, it didn't format.

01:10:10.176 --> 01:10:14.196
And I have learned that if it
doesn't format, I have put in invalid

01:10:14.196 --> 01:10:16.776
syntax somewhere for a moment.

01:10:16.776 --> 01:10:21.276
It was like, oh, export type
must not be a valid TS keyword.

01:10:21.666 --> 01:10:25.696
And then I finally realized, oh
wait, this is on prettier 1.19.

01:10:25.716 --> 01:10:29.406
That must predate that syntax
being added to TypeScript.

01:10:29.646 --> 01:10:34.296
And so I had to update prettier, but like
that's how much I have learned to lean on.

01:10:34.296 --> 01:10:37.086
You hit save and it
formats and it's valid.

01:10:37.721 --> 01:10:38.891
Carl: Yep, a hundred percent.

01:10:38.976 --> 01:10:40.571
I, I recognize that in myself as well.

01:10:41.051 --> 01:10:41.411
Okay.

01:10:41.471 --> 01:10:42.971
Let's wrap it up with some conferences.

01:10:43.241 --> 01:10:44.201
Mo: Let's jump into it.

01:10:44.201 --> 01:10:47.951
So we've hinted a few times
and I can now say that we've

01:10:47.951 --> 01:10:49.601
got Seth Webster's endorsement.

01:10:49.601 --> 01:10:54.461
So the executive director of the React
Foundations talks about my conference.

01:10:54.461 --> 01:10:55.361
I'm very happy today.

01:10:55.691 --> 01:10:58.781
We've been organizing this for the
second year, so React Native London

01:10:58.991 --> 01:11:02.861
for anyone who's a React native
enthusiast in London and beyond.

01:11:02.861 --> 01:11:05.231
We have people from Brazil and
India last year, so that's like the

01:11:05.231 --> 01:11:08.411
furthest extent that we have people
coming in from around the world.

01:11:08.741 --> 01:11:11.861
But if you are interested,
we've got our conference on

01:11:11.861 --> 01:11:13.631
the 13th and 14th of November.

01:11:14.046 --> 01:11:17.766
In Central London, we've got a beautiful
venue, some great talks from Meta, Amazon,

01:11:18.216 --> 01:11:22.656
Microsoft, and just a bunch of community
people from expo and independent app

01:11:22.656 --> 01:11:25.596
developers who are gonna come and give
some really, really phenomenal talks.

01:11:26.046 --> 01:11:31.116
Use the code TMIR 10 and you should get
a 10% discount on checking out, which

01:11:31.116 --> 01:11:37.056
will, if I'm doing my mental maths right,
make the ticket price 330 ish pounds

01:11:37.356 --> 01:11:41.826
for a two day conference to be able to
attend workshops and the conference day.

01:11:42.276 --> 01:11:46.686
Carl: Um, other ones we've got
coming up are Wey Wey Web November

01:11:46.686 --> 01:11:48.996
17th and 18th in Malaga, Spain.

01:11:49.206 --> 01:11:54.006
We've also got React Summit November
18th through 21st in New York.

01:11:54.096 --> 01:11:56.496
Mark: There's JS Nation on the 17th.

01:11:56.556 --> 01:12:00.456
There's in-person React Summit in
person on the 18th, and then they

01:12:00.456 --> 01:12:02.196
have an online day the next week.

01:12:02.271 --> 01:12:02.301
Okay.

01:12:02.991 --> 01:12:03.921
Carl: Oh, oh, oh yes.

01:12:03.921 --> 01:12:06.291
I see it's 18th and 20th, not through.

01:12:06.441 --> 01:12:06.951
Interesting.

01:12:07.191 --> 01:12:08.091
One day in person.

01:12:08.091 --> 01:12:08.841
One day online.

01:12:09.051 --> 01:12:09.351
Okay.

01:12:09.381 --> 01:12:09.831
Makes sense.

01:12:10.341 --> 01:12:13.041
There's also React Advanced
November 28th, also

01:12:13.041 --> 01:12:15.921
Mark: in London the
day after Thanksgiving.

01:12:16.311 --> 01:12:18.291
Someone in England didn't
think about that part.

01:12:18.861 --> 01:12:19.491
He, he, he,

01:12:19.701 --> 01:12:19.941
Carl: yeah.

01:12:19.941 --> 01:12:20.931
It's not for Americans.

01:12:21.471 --> 01:12:24.381
Mo: It's not just React Advance,
it's also Tech Lead Conf, which is

01:12:24.381 --> 01:12:27.501
also organized by the Ation folks
on the same day in London as well.

01:12:27.501 --> 01:12:31.161
So, no, I would doubt that there's
gonna be a lot of people from

01:12:31.161 --> 01:12:32.511
the states there, unfortunately.

01:12:32.961 --> 01:12:33.381
Carl: For sure.

01:12:33.891 --> 01:12:38.541
Well, I'll, I'll also add, I just saw
like two days ago, the organizer of

01:12:38.541 --> 01:12:43.551
React Paris posted in the events channel
here that CFP is open, so we gotta React

01:12:43.761 --> 01:12:45.861
Paris if you want to submit a talk.

01:12:46.161 --> 01:12:48.621
But that's gonna be in like March
though, so not anytime soon.

01:12:49.191 --> 01:12:49.911
That's all we got.

01:12:50.241 --> 01:12:53.061
Thanks so much for sticking
around for a whole 90 minutes.

01:12:53.151 --> 01:12:54.651
Mark: It was a very busy month.

01:12:54.681 --> 01:12:55.161
Okay.

01:12:55.521 --> 01:12:55.881
Carl: Yeah.

01:12:56.001 --> 01:12:59.751
We'll be back next month, on the
last Wednesday here in the live

01:12:59.751 --> 01:13:02.721
stage or back in your podcast
feed just as soon as we can.

01:13:03.201 --> 01:13:03.531
Yeah.

01:13:03.591 --> 01:13:04.161
Thanks so much.

01:13:04.641 --> 01:13:07.401
Well, normally we gather sources
from a variety of newsletters.

01:13:07.401 --> 01:13:10.401
We actually had so many things
that Mark shared in the tech

01:13:10.401 --> 01:13:14.211
reads and news chat this month
that I don't think any of us did.

01:13:14.641 --> 01:13:15.376
So that's cool.

01:13:15.706 --> 01:13:18.466
Mark: And I pasted a lot more links
in the discussion threads too.

01:13:18.766 --> 01:13:20.026
Carl: That's something I
should be better about.

01:13:20.026 --> 01:13:21.496
That would be lovely and helpful.

01:13:21.856 --> 01:13:24.616
But yeah, if you see anything
newsworthy, definitely let us know

01:13:24.616 --> 01:13:26.986
in the Tech News and Reads channel,
just like Mark has been doing.

01:13:27.376 --> 01:13:30.616
You can also email us at
hello@reactiveflex.com.

01:13:30.676 --> 01:13:33.766
But you know it's a community
like Join, participate.

01:13:34.186 --> 01:13:36.856
I do read every email though, so if
you send something I, I will read it.

01:13:37.096 --> 01:13:39.736
If this is a show that you get value
from and want to support, best way

01:13:39.736 --> 01:13:43.546
to do so is by submitting a review
wherever you listen and by telling

01:13:43.546 --> 01:13:44.626
your friends and coworkers about it.

01:13:44.776 --> 01:13:47.476
And go to a meetup and say, Hey,
there's this great podcast I love.

01:13:47.806 --> 01:13:48.226
Cheers.

01:13:48.556 --> 01:13:49.186
See you next month.