1
00:00:00,256 --> 00:00:01,606
Carl Vitullo: Hello,
thanks for joining us.

2
00:00:01,686 --> 00:00:05,826
This is June's edition of This Month
in React, where we recap and digest

3
00:00:05,836 --> 00:00:09,136
the recent developments in the ever
evolving React and web ecosystem.

4
00:00:09,466 --> 00:00:12,066
We're coming to you live from
Reactiflux, the place for

5
00:00:12,066 --> 00:00:13,386
professional React developers.

6
00:00:13,723 --> 00:00:18,053
I'm Carl, I'm a staff product developer
and freelance community manager here

7
00:00:18,063 --> 00:00:21,983
at Reactiflux, where I run community
programs like these events and build

8
00:00:21,983 --> 00:00:23,783
tools that help keep the community going.

9
00:00:24,076 --> 00:00:25,396
Mark Erikson: Hi, I'm Mark Erikson.

10
00:00:25,476 --> 00:00:26,966
My day job is working at Replay.

11
00:00:26,966 --> 00:00:30,036
io where we're building a time
traveling debugger for JavaScript.

12
00:00:30,476 --> 00:00:32,736
And outside of that, I do Redux stuff.

13
00:00:33,246 --> 00:00:33,806
Mo Khazali: Hi everyone.

14
00:00:33,916 --> 00:00:34,866
I'm Mo.

15
00:00:34,966 --> 00:00:36,656
I head the mobile team at Theodo.

16
00:00:36,726 --> 00:00:40,326
I'm quite active in the React Native
community and I organized the React

17
00:00:40,326 --> 00:00:44,356
Native London meetup and here and there
dabble in open source with a couple of

18
00:00:44,356 --> 00:00:45,966
libraries in the React Native ecosystem.

19
00:00:46,066 --> 00:00:46,946
Very happy to be here.

20
00:00:47,249 --> 00:00:49,489
Carl Vitullo: Uh, I'm just going
to start off with some quick hits

21
00:00:49,489 --> 00:00:51,409
of new releases and conferences.,

22
00:00:51,519 --> 00:00:56,709
Starting off immediately, because the
market, the job market is so bad, I've

23
00:00:56,709 --> 00:00:59,429
been reading off stuff from layoffs.fyi.

24
00:00:59,499 --> 00:01:01,899
We're not quite at the end of June,
it's a couple of days left at time

25
00:01:01,899 --> 00:01:04,819
of recording, but most of the way
through June, we're at about 9.

26
00:01:04,819 --> 00:01:11,330
2, 000 laid off from 40 companies,
which is down, I mean compared to six

27
00:01:11,330 --> 00:01:15,340
months ago we're down substantially,
but compared to two years ago we are up

28
00:01:15,340 --> 00:01:17,679
substantially, so it's still not great.

29
00:01:18,140 --> 00:01:23,030
I've seen some other broader metrics
trickling out from other places,

30
00:01:23,030 --> 00:01:25,996
like I saw a link from ADP that
I unfortunately don't have handy

31
00:01:26,206 --> 00:01:32,168
suggesting that the overall like,
tech market is at about 80 percent of

32
00:01:32,168 --> 00:01:35,548
it was, I believe, compared to 2018.

33
00:01:35,678 --> 00:01:40,078
Yeah, I, I found that really interesting
because between hearing headlines about

34
00:01:40,078 --> 00:01:44,711
like record hiring during the pandemic
and record layoffs in the two years, after

35
00:01:44,711 --> 00:01:46,518
that, it was like, Where do we end up?

36
00:01:46,648 --> 00:01:51,358
So that's the first data point I've seen,
uh, addressing that question of, like,

37
00:01:51,358 --> 00:01:56,198
what's the net gain loss, and it suggests
net loss of, like, 20%, which seems

38
00:01:56,258 --> 00:02:00,558
massive, but yeah, it's also, it's ADP,
I don't know how much to trust that, I

39
00:02:00,558 --> 00:02:05,188
would assume that they got a very large
sample size, but I'm not sure how they

40
00:02:05,188 --> 00:02:10,971
defined, like, tech, so, I don't really
know how to interpret that in, through

41
00:02:10,971 --> 00:02:12,331
a lens of like software development.

42
00:02:12,678 --> 00:02:14,678
But yeah, moving on to some new releases.

43
00:02:14,798 --> 00:02:15,338
There is TurboRepo 2.

44
00:02:15,338 --> 00:02:16,748
0.

45
00:02:16,838 --> 00:02:19,648
That's probably especially relevant
if you're doing stuff with Next.

46
00:02:19,844 --> 00:02:22,314
It looks like it's
mostly like a fancier UI.

47
00:02:22,314 --> 00:02:26,280
They're doing like a pretty
high effort in terminal UI.

48
00:02:26,290 --> 00:02:28,620
Like it's, you know,
reactive and interactive.

49
00:02:28,761 --> 00:02:34,174
And you can now break down your logs
on a per task basis rather than it

50
00:02:34,174 --> 00:02:38,154
just being, you know, a constant scroll
back the way terminals usually are.

51
00:02:38,478 --> 00:02:39,138
So that seems neat.

52
00:02:39,238 --> 00:02:41,868
Oh, they had some new docs, and
it looks like they included some,

53
00:02:41,878 --> 00:02:46,675
like, fundamental information
about Monorepos, which seems cool.

54
00:02:47,185 --> 00:02:49,775
React Admin released version five.

55
00:02:49,815 --> 00:02:53,710
We actually had Francois Zaniotto,
hope I'm not mispronouncing that,

56
00:02:53,760 --> 00:02:57,170
on as a guest a couple of weeks
ago, and I think he's super cool.

57
00:02:57,170 --> 00:03:01,010
I love his ethos for the company
that he's building, which maintains

58
00:03:01,040 --> 00:03:03,670
React Admin and does agency work.

59
00:03:04,010 --> 00:03:04,930
So I just wanted to shout that out.

60
00:03:05,010 --> 00:03:08,450
RS build released version 0.

61
00:03:08,450 --> 00:03:12,752
7, which they say is going to
be the last release before 1.

62
00:03:12,753 --> 00:03:12,952
0.

63
00:03:12,952 --> 00:03:13,762
Mark, you had some thoughts?

64
00:03:14,217 --> 00:03:17,937
Mark Erikson: ByteDance, the folks
behind TikTok, have a massive

65
00:03:18,137 --> 00:03:20,047
web tooling infrastructure team.

66
00:03:20,294 --> 00:03:24,921
They've actually rebuilt Webpack
in Rust, and I know that, you know,

67
00:03:24,921 --> 00:03:28,747
rewrite it in Rust is its own meme
at this point, but it seems like

68
00:03:28,747 --> 00:03:33,987
they've, they've truly built a Webpack
compatible version in Rust called RSPack.

69
00:03:34,301 --> 00:03:40,791
On top of that, they have a higher
level abstraction layer called RSBuild,

70
00:03:40,934 --> 00:03:45,967
which has an easier configuration
format, a little bit like ESBuild does.

71
00:03:46,217 --> 00:03:49,897
if you actually look in their docs, they
have a migration guide for switching

72
00:03:49,927 --> 00:03:52,474
from Create React app to RSBuild.

73
00:03:52,784 --> 00:03:55,514
I did that on a little side
project a few months ago.

74
00:03:55,574 --> 00:04:00,324
It was really easy to switch and
the compile time dropped from like

75
00:04:00,344 --> 00:04:02,364
30 seconds to less than a second.

76
00:04:02,731 --> 00:04:06,281
it feels like a, an actually
viable competitor tool.

77
00:04:06,781 --> 00:04:07,191
Carl Vitullo: Nice.

78
00:04:07,241 --> 00:04:07,821
Super cool.

79
00:04:08,371 --> 00:04:10,451
We've also got biome 1.

80
00:04:10,491 --> 00:04:10,771
8.

81
00:04:11,061 --> 00:04:11,311
Yeah.

82
00:04:11,311 --> 00:04:12,591
I have a soft spot for biome.

83
00:04:12,631 --> 00:04:14,531
I was an early supporter of Rome.

84
00:04:14,621 --> 00:04:17,874
I have been eager to see
what comes out of that.

85
00:04:17,884 --> 00:04:20,764
So yeah, it looks like they've
got like new support for CSS.

86
00:04:21,084 --> 00:04:25,294
They have better support for
language servers in workspaces, so

87
00:04:25,294 --> 00:04:28,154
if you've got like a big monorepo,
it should work a little bit better.

88
00:04:28,254 --> 00:04:32,604
New reporters, migration, some more
linting options, but yeah, Biome

89
00:04:32,614 --> 00:04:34,124
is like kind of an all in one.

90
00:04:34,134 --> 00:04:38,574
They try to do like formatting and
linting and, yeah, it's a bundle play.

91
00:04:38,574 --> 00:04:41,411
They're taking in a bunch of
tools that, were separate and

92
00:04:41,411 --> 00:04:42,861
doing it all as one package.

93
00:04:42,937 --> 00:04:44,287
Mark Erikson: And written in Rust.

94
00:04:44,621 --> 00:04:45,631
Carl Vitullo: Written in Rust.

95
00:04:45,671 --> 00:04:46,091
Sure.

96
00:04:46,161 --> 00:04:48,341
So super fast, blazing fast.

97
00:04:48,991 --> 00:04:50,591
Is blazing fast still cool?

98
00:04:51,101 --> 00:04:52,861
There's also Astro 4.

99
00:04:52,901 --> 00:04:53,411
10.

100
00:04:53,961 --> 00:04:57,201
I am hoping to play around
with Astro this month.

101
00:04:57,211 --> 00:05:00,241
So maybe I'll be able to actually,
you know, say some more intelligent

102
00:05:00,241 --> 00:05:01,801
things about what the experience is.

103
00:05:01,801 --> 00:05:03,811
But I, I know lots of
people who love the tool.

104
00:05:03,851 --> 00:05:06,541
It looks like some small
improvements, nothing too major.

105
00:05:06,971 --> 00:05:10,171
This is a new library to
me, Valibot released 0.31.

106
00:05:10,561 --> 00:05:15,601
It's a competitor to Zod, which does
like schema validation or, you know, data

107
00:05:15,601 --> 00:05:19,271
validation through a schema with like type
generation and all that kind of stuff.

108
00:05:19,464 --> 00:05:22,664
This looks like a pretty solid competitor.

109
00:05:22,664 --> 00:05:26,634
They talk about, tree shaking and
stuff, which I'm broadly skeptical

110
00:05:26,634 --> 00:05:28,504
of tree shaking as a general promise.

111
00:05:28,514 --> 00:05:30,074
It's very difficult to verify.

112
00:05:30,584 --> 00:05:33,311
Mark Erikson: My understanding is
that Zod, when you import it, you're

113
00:05:33,311 --> 00:05:38,861
basically importing a giant object that
has all the possible validation types

114
00:05:38,871 --> 00:05:43,727
built in, and I think Valobot's sales
pitch is that it's a bunch of individual

115
00:05:43,727 --> 00:05:47,787
functions, and so you would only
import the actual bits that you need.

116
00:05:47,912 --> 00:05:51,002
And therefore, you're not getting
a giant blob of runtime code.

117
00:05:51,386 --> 00:05:55,066
Carl Vitullo: Yeah, I think they said
it was like, could be up to like 95

118
00:05:55,076 --> 00:06:00,326
percent smaller than Zod, while also like
significantly simplifying the mental model

119
00:06:00,356 --> 00:06:02,749
of the schema and the type validation.

120
00:06:02,749 --> 00:06:06,879
If I can think about it less and
have it affect the size of my code

121
00:06:06,929 --> 00:06:09,929
less, like both of those sound
like things that I would want.

122
00:06:10,099 --> 00:06:13,163
Mo Khazali: I guess the thing is,
it's a question of how much you

123
00:06:13,163 --> 00:06:15,583
want to really optimize your bundle
size and at what stage you're at.

124
00:06:15,933 --> 00:06:19,840
If I'm recalling correctly, Zod
minified and gzipped was about

125
00:06:19,840 --> 00:06:22,080
60kb, something around that size.

126
00:06:22,330 --> 00:06:27,020
So it is quite a chunky library
to add into your dependencies.

127
00:06:27,090 --> 00:06:30,960
So, I guess if this actually delivers
on that promise and it's closer to

128
00:06:30,960 --> 00:06:34,677
90 percent less than that, which
is I guess 6kb, it wouldn't be

129
00:06:34,677 --> 00:06:37,230
too bad of a shave to do, I'd say.

130
00:06:37,347 --> 00:06:40,107
But, remains to be seen if it's
in practice going to be that good.

131
00:06:40,353 --> 00:06:43,233
Carl Vitullo: Yeah, I just pulled up
Bundlephobia for Zod, and it's, yep,

132
00:06:43,243 --> 00:06:46,613
61kb minified, 14kb minified and zipped.

133
00:06:46,793 --> 00:06:48,057
Which is Hefty.

134
00:06:48,067 --> 00:06:49,137
Yeah, that's enormous.

135
00:06:49,517 --> 00:06:50,687
That would give me a lot of pause.

136
00:06:51,197 --> 00:06:52,387
Onto some conferences.

137
00:06:52,457 --> 00:06:53,357
Mo, I think you had a few.

138
00:06:53,887 --> 00:06:54,897
Mo Khazali: Yeah, I'll jump right in.

139
00:06:54,897 --> 00:06:58,637
So, firstly, at the very beginning
of July, 4th to 5th of July,

140
00:06:58,687 --> 00:07:00,487
React Nexus is happening in India.

141
00:07:00,752 --> 00:07:04,712
One of the great conferences that I
attended last year, I really enjoyed.

142
00:07:04,782 --> 00:07:07,182
The crowd there was quite a,
quite a large crowd as well.

143
00:07:07,182 --> 00:07:08,862
I think there's about 500, 600 people.

144
00:07:08,922 --> 00:07:12,202
So a massive conference, but
people are so friendly and I got

145
00:07:12,202 --> 00:07:13,312
to meet a lot of lovely people.

146
00:07:13,312 --> 00:07:16,702
So would highly recommend if you're
sort of in the South Asia region

147
00:07:16,702 --> 00:07:19,582
to, to definitely give it a shot,
if you can make it to Bangalore.

148
00:07:19,968 --> 00:07:23,653
Mid July, we have Chain React and this
is hosted by the folks at Infinite Red.

149
00:07:23,903 --> 00:07:25,643
Another one of those great conferences.

150
00:07:25,779 --> 00:07:29,365
I've not been to Chain React myself,
but I'm, So involved in the React

151
00:07:29,365 --> 00:07:32,405
Native community that I get told every
year, why are you not at Chain React?

152
00:07:32,425 --> 00:07:34,515
And you're missing out on one
of the best conferences ever.

153
00:07:34,845 --> 00:07:37,793
So the FOMO hits real hard
every time around Chain React.

154
00:07:38,061 --> 00:07:40,551
The folks at Infinite Red are
absolutely amazing, and they

155
00:07:40,561 --> 00:07:44,531
organized an incredible conference
from all accounts that I've heard of.

156
00:07:44,906 --> 00:07:47,336
Everyone really loves Chain
React, so if you are in the U.

157
00:07:47,336 --> 00:07:47,616
S.

158
00:07:47,656 --> 00:07:50,366
and you're in the React Native
scene, you really do not want

159
00:07:50,366 --> 00:07:51,666
to be missing Chain React.

160
00:07:51,866 --> 00:07:52,706
If I was in the U.

161
00:07:52,706 --> 00:07:55,656
S., I would definitely be at Chain
React this month, so I cannot

162
00:07:55,656 --> 00:07:57,926
give it more praise than that.

163
00:07:58,336 --> 00:08:03,496
And then, lastly, towards the end of
July, we have GeekConf, so GeekConf

164
00:08:03,496 --> 00:08:05,896
is another sort of React Native
conference with a little bit of a

165
00:08:05,896 --> 00:08:07,626
blend of web as well added into it.

166
00:08:07,946 --> 00:08:10,506
So that's happening on the
25th of July in Berlin.

167
00:08:10,816 --> 00:08:14,846
There's also a day that's dedicated to
remote track, but 25th of July is the

168
00:08:14,846 --> 00:08:18,386
key date that's going to be happening
in person, and I'll be speaking at

169
00:08:18,386 --> 00:08:21,206
that conference as well, and hopefully
if any of you folks are there, please

170
00:08:21,206 --> 00:08:24,316
do come around and say hi, would be
lovely to meet some of you in person.

171
00:08:24,466 --> 00:08:25,006
Carl Vitullo: Heck yeah.

172
00:08:25,431 --> 00:08:29,735
Leaving the list of conferences that us
as hosts have personal experience with,

173
00:08:29,808 --> 00:08:34,838
there's a We Are Developers World Congress
in Berlin, July 17th through 19th.

174
00:08:35,508 --> 00:08:38,891
There's a CityJS in Singapore.

175
00:08:39,046 --> 00:08:42,126
That's going to be July 24th through 26th.

176
00:08:42,606 --> 00:08:46,506
We love JS in Amsterdam in the
Netherlands, August 9th and 10th.

177
00:08:46,756 --> 00:08:50,716
And then the last conference that we're
highlighting in the next two months is

178
00:08:50,726 --> 00:08:54,910
React Rally, which is going to be August
12th through 13th in Salt Lake City.

179
00:08:55,060 --> 00:08:57,890
Actually, I have been to that one in
the past and it was pretty quality.

180
00:08:58,143 --> 00:08:59,576
Mark Erikson: Yeah, I, I would also.

181
00:08:59,608 --> 00:09:02,488
Emphasize like React
Rally has been fantastic.

182
00:09:02,811 --> 00:09:03,971
the organizers are great.

183
00:09:04,031 --> 00:09:06,791
they do a really good job of
giving it a good community feel.

184
00:09:07,061 --> 00:09:10,381
I was there last year and attendance was
unfortunately just a little down because

185
00:09:10,381 --> 00:09:12,191
of trying to revive it after COVID.

186
00:09:12,521 --> 00:09:17,821
So if, if you can all make it to
React Rally in August, please go.

187
00:09:17,821 --> 00:09:19,696
It's, it's totally worth, worth it.

188
00:09:19,926 --> 00:09:23,626
Carl Vitullo: Yeah, and it's the home
neighborhood for a lot of really big

189
00:09:23,626 --> 00:09:25,606
people in the React and web ecosystem.

190
00:09:25,653 --> 00:09:28,386
there are quite a number of
people who live generally in

191
00:09:28,396 --> 00:09:30,236
Utah and in Salt Lake City.

192
00:09:30,466 --> 00:09:31,016
I think Kent C.

193
00:09:31,016 --> 00:09:32,046
Dodds is out there.

194
00:09:32,283 --> 00:09:33,673
Mark Erikson: Kent, Tanner, Ryan.

195
00:09:33,976 --> 00:09:35,306
Carl Vitullo: Yeah, it's
their home neighborhood.

196
00:09:35,316 --> 00:09:37,326
I assume they'll be at the conference.

197
00:09:37,356 --> 00:09:38,946
Yeah, anyway, cool.

198
00:09:38,986 --> 00:09:42,166
All right, moving on to some
of our main content here.

199
00:09:42,236 --> 00:09:43,186
Mark, you want to start us off?

200
00:09:43,206 --> 00:09:44,676
Mark Erikson: Boy, oh boy, oh boy.

201
00:09:44,990 --> 00:09:48,383
Okay, welcome to SuspenseGate.

202
00:09:49,043 --> 00:09:53,323
So, for the for those of you who
may not have been following all the

203
00:09:53,323 --> 00:09:55,637
drama on Twitter, we're here for you.

204
00:09:55,897 --> 00:10:00,857
About a month ish ago, a month and a half
ish ago, Andrew Clark actually tweeted

205
00:10:00,887 --> 00:10:06,497
that, We've, we've updated to a new React
19 release candidate, and we think that

206
00:10:06,507 --> 00:10:10,914
this release candidate is going to be
the final one, like, these are the actual

207
00:10:10,914 --> 00:10:16,790
bytes we plan to release as React 19,
unless there's any other major changes.

208
00:10:17,037 --> 00:10:19,437
Well, there is now
cause for major changes.

209
00:10:19,807 --> 00:10:24,170
And in fact, React 19 has been
delayed semi indefinitely.

210
00:10:24,250 --> 00:10:28,130
The React team is going to be doing
some updates, and we don't know

211
00:10:28,140 --> 00:10:29,560
how long that's going to take.

212
00:10:29,777 --> 00:10:31,997
Why are they doing these updates?

213
00:10:32,327 --> 00:10:36,317
In November of last year, Andrew
Clark put up a PR that changed the

214
00:10:36,317 --> 00:10:41,367
behavior of the suspense component
and how it manages loading children

215
00:10:41,453 --> 00:10:43,753
that are suspending to fetch data.

216
00:10:44,068 --> 00:10:48,815
Previously, if you had multiple
children inside of suspense, And

217
00:10:48,815 --> 00:10:50,895
they all wanted to fetch some data.

218
00:10:51,110 --> 00:10:55,390
The suspense component would give each
of these components a chance to start

219
00:10:55,420 --> 00:10:57,478
rendering and start the data fetching.

220
00:10:57,748 --> 00:11:02,752
And then actually pause and
wait for all of the components

221
00:11:02,752 --> 00:11:04,022
to finish fetching their data.

222
00:11:04,234 --> 00:11:07,104
Doing it all in parallel,
kind of like a promise.

223
00:11:07,414 --> 00:11:08,734
all combination.

224
00:11:09,146 --> 00:11:12,426
And with this PR, the
React team changed it.

225
00:11:12,651 --> 00:11:18,791
So that React really only gives the
first child that suspends a chance to

226
00:11:18,791 --> 00:11:24,149
fetch, and then it waits for that child
to finish loading its data, tries to re

227
00:11:24,149 --> 00:11:28,652
render, and then keeps going until the
next child component tries to fetch data.

228
00:11:28,921 --> 00:11:32,251
Basically doing all of
that in serial instead.

229
00:11:32,517 --> 00:11:37,447
Now, they, if you look at the PR, Andrew
listed some potential reasons for this.

230
00:11:37,558 --> 00:11:40,559
One is that this actually made Facebook.

231
00:11:40,599 --> 00:11:42,487
com load a little faster.

232
00:11:42,692 --> 00:11:47,265
But also, it has to do with
how the React team thinks.

233
00:11:47,385 --> 00:11:51,095
that people should be doing data
fetching on the client side.

234
00:11:51,318 --> 00:11:56,151
And basically their argument is, you,
you shouldn't be doing data fetching

235
00:11:56,231 --> 00:11:58,581
nested deep in the component tree.

236
00:11:58,872 --> 00:12:03,119
Instead, you should hoist it
up to the top at like the route

237
00:12:03,119 --> 00:12:05,174
level or the page level instead.

238
00:12:05,450 --> 00:12:08,320
And so their argument is like,
well, we don't think people should

239
00:12:08,330 --> 00:12:10,840
be doing this pattern much anyway.

240
00:12:11,059 --> 00:12:12,499
So it's okay for us to change it.

241
00:12:12,772 --> 00:12:16,361
Now, this was done as part of
React 19's development, and

242
00:12:16,361 --> 00:12:18,181
React 19 is a major version.

243
00:12:18,491 --> 00:12:21,160
So you can totally,
you know, make changes.

244
00:12:21,220 --> 00:12:24,090
It's, it's legal under the
terms of semantic versioning.

245
00:12:24,232 --> 00:12:29,168
And this was available in the React
19 Canaries, but as we all know,

246
00:12:29,178 --> 00:12:33,678
nobody actually tries out pre release
versions, everyone waits until

247
00:12:33,678 --> 00:12:37,798
it's actually released, and then
tries it, and then reports bugs.

248
00:12:38,031 --> 00:12:42,337
So, this basically went unnoticed
by the community for months.

249
00:12:42,540 --> 00:12:48,228
And about a month ago, someone mentioned
it on Twitter, very briefly, and TK Dodo,

250
00:12:48,228 --> 00:12:52,389
the maintainer of React Query, Saw that
comment and said, oh, that doesn't look

251
00:12:52,419 --> 00:12:54,399
great, and then didn't think about it.

252
00:12:54,609 --> 00:12:58,565
And then just a couple weeks later,
there was another discussion thread,

253
00:12:58,624 --> 00:13:03,239
and suddenly TK Dodo and a bunch of
other people began to realize, wait

254
00:13:03,239 --> 00:13:08,269
a minute, this is actually a very
significant change in how suspense works.

255
00:13:08,553 --> 00:13:13,803
And in particular, the React 3 Fiber
developers, which is the React for

256
00:13:13,833 --> 00:13:19,322
3D game engines, Realized we depend
on suspense heavily because we need

257
00:13:19,332 --> 00:13:23,672
to be able to load a lot of different
things async like game assets.

258
00:13:23,752 --> 00:13:29,603
So it's not just about data fetching,
it's about lots of other async behavior.

259
00:13:29,891 --> 00:13:33,409
And they, and they started
showing demos where, everything

260
00:13:33,409 --> 00:13:37,799
went from loading in parallel to
loading as a waterfall in serial.

261
00:13:38,079 --> 00:13:42,126
And now example apps were
way, way slower as a result.

262
00:13:42,423 --> 00:13:44,253
There was a massive firestorm on Twitter.

263
00:13:44,749 --> 00:13:48,983
A day or so later, Sophie Alpert from
the React team said, We talked about

264
00:13:48,983 --> 00:13:50,803
this in a React team meeting today.

265
00:13:51,098 --> 00:13:54,338
We didn't realize how many
people would be affected by this.

266
00:13:54,638 --> 00:13:58,888
But also, this was a very major
change to React's internals.

267
00:13:59,188 --> 00:14:01,548
We did this, like, seven months ago.

268
00:14:01,755 --> 00:14:05,565
We've continued making lots more
changes to the internal since then.

269
00:14:05,895 --> 00:14:08,731
We can't just roll back this change.

270
00:14:09,077 --> 00:14:14,431
We know what we would need to do in order
to re enable the old behavior, but it's

271
00:14:14,431 --> 00:14:18,731
going to take another fairly significant
set of internal changes to do that.

272
00:14:19,341 --> 00:14:22,162
So, we don't know when we're
going to get around to it.

273
00:14:22,369 --> 00:14:25,919
Stepping back for a second, at
that point in time, the community

274
00:14:25,919 --> 00:14:30,074
conclusions were, they already said
React 19 is release candidate and

275
00:14:30,074 --> 00:14:34,851
ready to ship, and we don't, like, we
know this would take major changes.

276
00:14:35,053 --> 00:14:40,529
Therefore, the conclusion was React 19 is
about to ship with this behavior and we're

277
00:14:40,529 --> 00:14:45,319
all going to be stuck with it for the
duration of React 19 as a major release.

278
00:14:45,543 --> 00:14:49,473
Carl Vitullo: Yeah, I don't know, some
of the like firestorm framing for this,

279
00:14:49,493 --> 00:14:53,143
it makes me a little bit like, I don't
know, it's, okay, this was a, this was

280
00:14:53,143 --> 00:14:58,061
a confusing behavior, and something
that they overlooked, but I am glad

281
00:14:58,071 --> 00:14:59,611
that this conversation did happen.

282
00:14:59,621 --> 00:15:05,434
And ultimately, the React team had this
pointed out to them and did respond

283
00:15:05,444 --> 00:15:06,864
ultimately, I think, appropriately.

284
00:15:06,884 --> 00:15:10,724
So, like, it's, I don't know, how do you,
How do you do open source development

285
00:15:10,734 --> 00:15:15,111
with millions of people, very few of
whom actually try out pre releases?

286
00:15:15,414 --> 00:15:18,134
Mark Erikson: Yeah, that actually
even ties into the events this

287
00:15:18,134 --> 00:15:22,484
week of Jordan Harband and some
of the package updates going on.

288
00:15:22,578 --> 00:15:23,864
Mo, you had a thought?

289
00:15:24,029 --> 00:15:27,259
Mo Khazali: Well, I was just thinking,
well, firstly, ironically, I remember when

290
00:15:27,259 --> 00:15:30,579
we did the last, last month's episode,
we were talking about how this might

291
00:15:30,579 --> 00:15:34,373
be like the quickest release cycle for
React, or, well, you know, it'll be a

292
00:15:34,373 --> 00:15:37,723
quick transition into Release Candidate
and then released, and then this came up.

293
00:15:37,723 --> 00:15:39,719
So I find that quite funny that
sometimes these things will

294
00:15:39,719 --> 00:15:41,059
come up and we can't predict it.

295
00:15:41,359 --> 00:15:46,668
But I think it's, you know, around the
whole expecting people to test canaries

296
00:15:46,668 --> 00:15:50,438
and, and release candidates, I almost
wonder if there's a different way that

297
00:15:50,438 --> 00:15:54,238
that needs to be done and if there's some
level of automation that can be done to

298
00:15:54,243 --> 00:15:58,708
ensure that not just, you know, apps that
are using RSCs and are, you know, the

299
00:15:58,708 --> 00:16:02,728
most up to date and exactly architected
in a way where Meta wants them to be

300
00:16:02,728 --> 00:16:06,561
architected, are tested, but rather,
there's a whole wide range of apps,

301
00:16:06,651 --> 00:16:09,631
ones that are built over a long period
of time, there might be SPAs or other

302
00:16:09,631 --> 00:16:11,451
things like that, all of those get tested.

303
00:16:11,701 --> 00:16:14,331
I don't know if there's a nicer way
to handle that, but I feel like just

304
00:16:14,441 --> 00:16:19,905
expecting people to test Canaries and
test RCs will not catch stuff like this

305
00:16:20,085 --> 00:16:23,945
.
Mark Erikson: That's the thing, I
believe the Vue ecosystem has like a

306
00:16:23,955 --> 00:16:29,045
full fledged, I don't know the right term
for it, they have a massive automation

307
00:16:29,055 --> 00:16:34,538
setup that tests all kinds of libraries
across the ecosystem against the latest

308
00:16:34,548 --> 00:16:39,728
versions of like Vue and Vuex and Pinia
and Vue Router and all these other tools.

309
00:16:39,988 --> 00:16:45,057
And similarly TypeScript, every time you
push a PR to TypeScript, it does checks

310
00:16:45,104 --> 00:16:49,987
against almost all of DefinitelyTyped,
or at least like a, the most widely used

311
00:16:49,997 --> 00:16:55,074
libraries on, on DefinitelyTyped and
across the ecosystem, to try to catch

312
00:16:55,084 --> 00:16:56,564
a lot of these issues ahead of time.

313
00:16:56,804 --> 00:17:01,384
But even then, there's a distinction
between, do the library's tests fail,

314
00:17:01,514 --> 00:17:03,299
and how are people using that library.

315
00:17:03,299 --> 00:17:09,399
I think in this case, React Query
had one test that did parallel

316
00:17:09,409 --> 00:17:13,239
fetching in a suspense, but it was
like two components running locally.

317
00:17:13,342 --> 00:17:16,662
And so the effects of it would
not have been meaningfully

318
00:17:16,792 --> 00:17:18,552
visible in terms of timing.

319
00:17:18,796 --> 00:17:19,276
Carl Vitullo: Right.

320
00:17:19,402 --> 00:17:19,702
Right.

321
00:17:19,712 --> 00:17:23,882
And ultimately this is a like
timing and parallelism issue.

322
00:17:23,932 --> 00:17:28,602
And I don't know, I'm not sure that
that's something that would work.

323
00:17:28,734 --> 00:17:30,654
have been proactively tested?

324
00:17:30,714 --> 00:17:34,817
Like, I'm not sure that it's something
that An automated test suite could

325
00:17:34,817 --> 00:17:37,784
like reasonably easily evaluate.

326
00:17:37,824 --> 00:17:41,501
And I'm not sure that someone would
have said, Oh, this is a large enough

327
00:17:41,501 --> 00:17:44,524
risk that we need to invest, you know,
several days of engineering time in

328
00:17:44,524 --> 00:17:48,751
order to make sure that we have test
coverage that will flag this if it breaks.

329
00:17:48,771 --> 00:17:52,184
So I don't know, I, to me,
this is just like such a.

330
00:17:52,356 --> 00:17:56,722
Niche interaction between, you know,
it's, it's such a corner case between

331
00:17:56,722 --> 00:18:01,442
the assumptions of the React core team
and the, you know, evaluation work that

332
00:18:01,452 --> 00:18:06,049
they do against the Facebook project
and the, you know, broader needs.

333
00:18:06,049 --> 00:18:11,414
So like, I don't know, I saw various
negative takes, like, oh, I don't

334
00:18:11,414 --> 00:18:14,234
know, I saw lots of various negative
takes, I'm not even gonna try

335
00:18:14,234 --> 00:18:16,144
and imagine, try and make up one.

336
00:18:16,574 --> 00:18:19,969
Mark Erikson: the React Summit organizers
for the last couple years Have done

337
00:18:19,999 --> 00:18:23,979
an event that they call the React
ecosystem contributors summit, where

338
00:18:23,979 --> 00:18:30,016
they get like 25 to 30 maintainers
and contributors to various tools

339
00:18:30,016 --> 00:18:31,746
and libraries together in a room.

340
00:18:32,019 --> 00:18:36,349
And they just give us a chance to
vote on whatever topics we think would

341
00:18:36,359 --> 00:18:42,382
be worth discussing and then give
us three hours to, talk about it in

342
00:18:42,382 --> 00:18:43,882
whatever way we think would be useful.

343
00:18:44,216 --> 00:18:45,676
So, I was there.

344
00:18:45,766 --> 00:18:47,676
There were two topics that were discussed.

345
00:18:47,899 --> 00:18:51,876
Two thirds of the room was discussing
the technical aspects of the suspense

346
00:18:51,876 --> 00:18:56,006
change,  two thirds of the group was
discussing the technical behaviors.

347
00:18:56,136 --> 00:19:00,996
One third of us were discussing, how
can we have better communication and

348
00:19:01,206 --> 00:19:02,896
interactions with the React team.

349
00:19:03,077 --> 00:19:06,494
A couple of days later, Joe Savona
from the React team put up a long

350
00:19:06,494 --> 00:19:10,174
Twitter thread, which is very,
very good and very worth reading.

351
00:19:10,284 --> 00:19:15,347
And he said, number one, we're going
to hold off on the React 19 release.

352
00:19:15,497 --> 00:19:18,287
We agree that this is a
major behavior change.

353
00:19:18,411 --> 00:19:22,334
And frankly, we underestimated
how many people would be

354
00:19:22,334 --> 00:19:24,501
affected by this pattern change.

355
00:19:24,734 --> 00:19:29,131
So they're going to step back and
they're going to do something to do it.

356
00:19:29,317 --> 00:19:34,741
My, my, my assumption is trying to
do the actual work to re implement

357
00:19:34,751 --> 00:19:38,064
some of the older behavior in
the, in the reconciler internals.

358
00:19:38,324 --> 00:19:39,334
So that's good.

359
00:19:39,424 --> 00:19:42,387
Like the community complained,
we communicated, they

360
00:19:42,457 --> 00:19:43,797
listened, they changed plans.

361
00:19:43,817 --> 00:19:47,147
These are all actually very,
very good things, but that ties

362
00:19:47,147 --> 00:19:48,537
into the communications question.

363
00:19:48,637 --> 00:19:54,461
Like a semi official way to communicate
to the React team is by filing an

364
00:19:54,461 --> 00:19:59,264
issue, and the React issues are
basically useless in that sense.

365
00:19:59,431 --> 00:20:02,854
One thing, they've been full of spam,
both in terms of like really, really old

366
00:20:02,874 --> 00:20:07,807
issues and literal, literal spam issues,
but also like the React team doesn't pay

367
00:20:07,807 --> 00:20:10,486
tons of attention to their issues list.

368
00:20:10,746 --> 00:20:14,326
And so just filing an issue
is not necessarily going to

369
00:20:14,326 --> 00:20:16,346
get like a quick response.

370
00:20:16,599 --> 00:20:20,135
There's Twitter, and a lot of the,
you know, React team members are

371
00:20:20,135 --> 00:20:23,498
very active on Twitter, and that's
great, but it's also not like a

372
00:20:23,508 --> 00:20:25,458
formal communications channel.

373
00:20:25,702 --> 00:20:31,271
So, what we concluded in our little set
of people talking during this Contributors

374
00:20:31,271 --> 00:20:36,295
Summit, is that we really need to bring
back this idea of a working group.

375
00:20:36,565 --> 00:20:41,166
For React 18, the React team put
together a React 18 working group

376
00:20:41,226 --> 00:20:45,786
where they specifically invited 50 to
75 people from across the ecosystem

377
00:20:45,863 --> 00:20:48,123
and continued adding to it over time.

378
00:20:48,348 --> 00:20:54,141
And there was a public GitHub repo
where the React team and the invited

379
00:20:54,141 --> 00:20:55,781
contributors could write comments.

380
00:20:55,965 --> 00:21:00,015
Anybody could read it, so the discussions
were public, but the idea was have

381
00:21:00,015 --> 00:21:05,161
a high signal ratio of meaningful
discussions and questions about React

382
00:21:05,161 --> 00:21:10,476
18, how things worked, how people could
actually use some of the features and

383
00:21:10,476 --> 00:21:12,116
what the practical results would be.

384
00:21:12,365 --> 00:21:14,335
And I think that was a great success.

385
00:21:14,695 --> 00:21:18,003
Like, there was a lot of really
good information in that repo.

386
00:21:18,333 --> 00:21:22,443
So our conclusion, as the little group
of people talking amongst ourselves,

387
00:21:22,443 --> 00:21:27,051
was we should somehow have a permanent
version of the working group.

388
00:21:27,283 --> 00:21:30,863
And actually, Tanner Linsley
independently tweeted the same

389
00:21:30,873 --> 00:21:32,882
thing a few days later, as well.

390
00:21:33,070 --> 00:21:38,326
So along with that, Joe Savona also
said in his tweet thread that we are

391
00:21:38,356 --> 00:21:43,660
actively looking at how can we get
more feedback on pre release versions

392
00:21:43,700 --> 00:21:47,245
and how we can actually Have better
communication with the community.

393
00:21:47,608 --> 00:21:51,938
So, I don't know exactly what will
happen, but I'm hopeful that something

394
00:21:51,938 --> 00:21:55,181
like this working group model
would be an option going forward.

395
00:21:55,501 --> 00:21:58,191
Mo Khazali: That's not, you know, too far
away from how the React Native team does

396
00:21:58,191 --> 00:22:01,581
it, you know, for, for the past couple of
years, I'd say, since, you know, Nicola

397
00:22:01,581 --> 00:22:05,808
Corti and Riccardo have come into the
React Native team, they've been pushing

398
00:22:05,808 --> 00:22:09,498
this sort of release cycle where they'll
have two, three different people from the

399
00:22:09,498 --> 00:22:12,888
community owning the release process for
each version of React Native that comes

400
00:22:12,888 --> 00:22:17,481
out, and that Inherently add some level
of community involvement to the releases.

401
00:22:17,635 --> 00:22:20,491
Obviously a working group with more and
more and more people, you know, about 60,

402
00:22:20,491 --> 00:22:23,791
70 people sounds like there's going to
be even more exposure, which is great.

403
00:22:24,041 --> 00:22:26,338
But I think it's, it's something that
could take a page out of the React

404
00:22:26,338 --> 00:22:29,248
native core teams book as well, because
they've done it successfully there.

405
00:22:29,538 --> 00:22:34,175
Mark Erikson: Overall, takeaways are,
nobody tries pre release versions, we

406
00:22:34,175 --> 00:22:38,485
really need a formal communications
channel between the React team and the

407
00:22:38,485 --> 00:22:42,098
community that they will pay attention
to, and that we can collectively

408
00:22:42,098 --> 00:22:44,533
offer feedback that they will see.

409
00:22:44,743 --> 00:22:48,360
Carl Vitullo: Yeah, I, I, I chimed in on
that because I don't know, Reactiflux,

410
00:22:48,370 --> 00:22:50,643
we're a thriving subset of the community.

411
00:22:50,683 --> 00:22:54,280
Maybe we could be a neutral space
for that type of communication to

412
00:22:54,290 --> 00:22:58,550
happen where they don't need to own
the moderation side of things that

413
00:22:58,570 --> 00:23:00,400
has not turned into a conversation.

414
00:23:00,440 --> 00:23:03,256
So, hey, maybe it will
eventually, but yeah.

415
00:23:03,641 --> 00:23:09,441
Twitter is definitely, I'm not sure how
effective it was ever as like a DevRel,

416
00:23:09,441 --> 00:23:12,891
you know, source of truth, but now, like,
if you don't have an account, they don't

417
00:23:12,891 --> 00:23:19,931
even let you view tweets, so, I think it
is past time, well past time for DevRel

418
00:23:19,951 --> 00:23:22,703
from the React team to go somewhere else.

419
00:23:22,763 --> 00:23:25,666
Like it is, it's been over a
month since the last blog post.

420
00:23:25,736 --> 00:23:31,626
And other than that, I don't know where
any communications from the React team

421
00:23:31,676 --> 00:23:33,776
out to the broader community come from.

422
00:23:33,806 --> 00:23:36,486
It's basically the blog and the
Twitter and the blog is not active.

423
00:23:36,486 --> 00:23:36,766
So.

424
00:23:37,040 --> 00:23:41,093
Yeah, I hope that that working
group concept turns into

425
00:23:41,093 --> 00:23:42,443
something a little more effective.

426
00:23:42,443 --> 00:23:44,233
But yeah, okay, cool.

427
00:23:44,363 --> 00:23:46,793
Next subject, TC39 proposals.

428
00:23:46,843 --> 00:23:48,426
A bunch just came out.

429
00:23:48,486 --> 00:23:50,976
I'm just going to kind of run
through this on the high level.

430
00:23:51,026 --> 00:23:51,596
Yeah, promise.

431
00:23:51,746 --> 00:23:54,936
try, it looks like it's pretty much
just like a quick wrapper on, , you

432
00:23:54,936 --> 00:23:58,020
know, new promise, and then you
immediately resolve with a value.

433
00:23:58,110 --> 00:24:01,010
I've done that a number of times, so
I guess there's a use case for this,

434
00:24:01,010 --> 00:24:05,270
but in the abstract I'm not really
coming up with a great example of

435
00:24:05,270 --> 00:24:09,190
why you would want to just Take a
synchronous value and make it a promise.

436
00:24:09,540 --> 00:24:12,760
Deferred import evaluation seems useful.

437
00:24:12,760 --> 00:24:18,313
it's a way, it's a way of delaying
execution of some parts of the import

438
00:24:18,313 --> 00:24:20,213
process when you're getting a module in.

439
00:24:20,583 --> 00:24:23,530
You can, you know, mark it as
deferred so that it will not

440
00:24:23,550 --> 00:24:25,220
actually evaluate the module.

441
00:24:25,220 --> 00:24:28,740
It'll still like parse it and do
some other interpretation steps

442
00:24:28,780 --> 00:24:30,440
that I'm blanking out at the moment.

443
00:24:30,568 --> 00:24:33,788
But it will not actually
evaluate the code until later on.

444
00:24:34,578 --> 00:24:36,178
Mark Erikson: Basically this, this allows.

445
00:24:36,243 --> 00:24:41,183
Speeding up, like the initialization
process by not running all the

446
00:24:41,183 --> 00:24:45,470
code in the application right away
on startup, even though you know,

447
00:24:45,470 --> 00:24:47,530
you'll need some of that code later.

448
00:24:48,040 --> 00:24:48,350
Carl Vitullo: Yeah.

449
00:24:48,350 --> 00:24:48,650
Okay.

450
00:24:48,740 --> 00:24:49,140
There we go.

451
00:24:49,660 --> 00:24:51,290
Another one was joint iteration.

452
00:24:51,320 --> 00:24:54,810
I thought this was pretty cool because
I've needed this a number of times.

453
00:24:54,820 --> 00:24:57,450
It's a way of iterating
over more than one.

454
00:24:57,450 --> 00:24:59,043
iterable at the same time.

455
00:24:59,163 --> 00:25:00,613
That's on stage 2.

456
00:25:00,613 --> 00:25:02,823
7, which means it's still
pretty far from getting shipped.

457
00:25:03,150 --> 00:25:03,906
Error.

458
00:25:03,906 --> 00:25:06,993
isError seems very useful for, for types.

459
00:25:07,103 --> 00:25:10,630
I guess lots of new stuff is moving down
the pipe, I don't know how many of these

460
00:25:10,630 --> 00:25:15,470
are super important to call out in great
detail, but yeah, Mark, Mo, anything that

461
00:25:15,470 --> 00:25:17,450
caught your eye is particularly important?

462
00:25:18,050 --> 00:25:20,230
Mo Khazali: I, I really think
Error.isError is the one

463
00:25:20,230 --> 00:25:21,630
that I'm most interested in.

464
00:25:21,750 --> 00:25:24,930
Obviously quite a while away
before it gets to adoption.

465
00:25:24,980 --> 00:25:29,176
It's still on the process step two,
it's stage two, but hopefully very soon.

466
00:25:29,206 --> 00:25:30,996
Well, I don't know how long this
process is going to take for them.

467
00:25:31,256 --> 00:25:31,896
It was interesting.

468
00:25:31,896 --> 00:25:37,096
The TC39 meeting that they had was
happening in Helsinki, uh, near Future

469
00:25:37,096 --> 00:25:39,546
Frontend, which was a conference that
we gave a shout out to last month.

470
00:25:39,546 --> 00:25:40,386
And I happened to be there.

471
00:25:40,635 --> 00:25:43,675
That was quite cool to see some of
these folks gather together and how they

472
00:25:43,685 --> 00:25:45,115
chatted about some of these standards.

473
00:25:45,115 --> 00:25:47,325
Just being privy to those
conversations was fascinating.

474
00:25:47,608 --> 00:25:50,621
So they have a, they have an
incredible process that I've, I've

475
00:25:50,621 --> 00:25:53,391
not seen anything like before in
any other sort of working group.

476
00:25:53,391 --> 00:25:55,068
So quite interesting, would recommend.

477
00:25:55,078 --> 00:25:58,268
There's a, if you go onto the Future
Frontend streams, they actually have

478
00:25:58,278 --> 00:26:02,068
a big panel discussion for, from the
second day of Future Frontend, and

479
00:26:02,098 --> 00:26:05,268
they actually discuss some of these
proposals in detail, which is quite cool.

480
00:26:05,828 --> 00:26:08,558
Carl Vitullo: All right,
let's move on to the next one.

481
00:26:08,758 --> 00:26:12,418
This is, I'm, CodeMod they announced
they are partnering with the React

482
00:26:12,418 --> 00:26:16,181
team to help migrate to React 19.

483
00:26:16,182 --> 00:26:20,031
I know, I feel like the React
team initially popularized

484
00:26:20,061 --> 00:26:21,561
the idea of CodeMods.

485
00:26:21,571 --> 00:26:23,801
So this is like not a
surprise at all to me.

486
00:26:24,051 --> 00:26:27,211
I guess I wasn't really familiar,
wasn't really aware of Codemod

487
00:26:27,211 --> 00:26:29,221
as like its own separate team.

488
00:26:29,571 --> 00:26:34,588
I see, you know, this is posted by the
founder of CEO of Codemod, I guess.

489
00:26:34,598 --> 00:26:36,155
So that's kind of news to me.

490
00:26:36,165 --> 00:26:39,495
But yeah, so there's gonna be more
Codemods, I guess, to help your

491
00:26:39,495 --> 00:26:42,408
codebase stay up to date with React 19.

492
00:26:42,658 --> 00:26:45,928
Mark Erikson: I am very familiar with
code not code mods as a technical

493
00:26:45,938 --> 00:26:51,371
concept I had no idea there was an entire
company devoted to building tools for

494
00:26:51,371 --> 00:26:53,761
code mods as like a corporate thing.

495
00:26:53,985 --> 00:26:57,241
Carl Vitullo: Right, right as a
technical thing Very familiar.

496
00:26:57,291 --> 00:27:00,318
I don't really understand what the
business case for that would be.

497
00:27:00,338 --> 00:27:01,908
I don't know, I guess maybe consulting.

498
00:27:01,938 --> 00:27:03,198
Maybe it's a services business.

499
00:27:03,298 --> 00:27:07,058
Mo Khazali: Apparently the way that
they also make it more effective is that

500
00:27:07,058 --> 00:27:09,668
they apparently pair it with some AI.

501
00:27:09,668 --> 00:27:12,558
It might be a pivot, I don't know,
but apparently they pair it with

502
00:27:12,558 --> 00:27:15,998
some AI and some nice CLI tools to
make your code mods more effective.

503
00:27:16,155 --> 00:27:19,365
That's not an endorsement, I
don't know if it works well, but

504
00:27:19,365 --> 00:27:20,245
that's seemingly their model.

505
00:27:20,595 --> 00:27:22,700
Carl Vitullo: Makes me a little
skeptical, but yeah, I don't know.

506
00:27:22,720 --> 00:27:24,260
Codemods generally are great.

507
00:27:24,320 --> 00:27:29,050
Any migrations and like major refactorings
like that are definitely substantially

508
00:27:29,050 --> 00:27:34,116
helped by having automated tools that do,
you know, even if it's like 60 to 80%,

509
00:27:34,146 --> 00:27:36,116
that's still pretty great, but yeah, cool.

510
00:27:36,156 --> 00:27:38,576
So there's an official partnership there.

511
00:27:38,586 --> 00:27:41,936
So I guess there's a business that is
writing these codemods and the React

512
00:27:41,936 --> 00:27:45,246
team is in collaboration with them
to make sure that they work well.

513
00:27:45,683 --> 00:27:46,083
That's cool.

514
00:27:46,113 --> 00:27:46,533
That's great.

515
00:27:46,566 --> 00:27:49,793
Love that it's not just the core team
trying to do everything on their own.

516
00:27:50,043 --> 00:27:52,463
Yeah, Mark, you want to take
us on to React Compiler?

517
00:27:52,863 --> 00:27:53,233
Mark Erikson: Sure.

518
00:27:53,403 --> 00:27:58,673
So, React Compiler came out in beta at
ReactConf, and so we're starting to get,

519
00:27:58,713 --> 00:28:03,073
you know, various examples of people
trying it out hands on in the real world.

520
00:28:03,210 --> 00:28:07,330
There was a very good post from Nadia
Makarevich, I believe is the name, who

521
00:28:07,330 --> 00:28:11,320
has written a number of excellent articles
about React rendering in the past.

522
00:28:11,395 --> 00:28:16,845
And she tried it out on both some
toy applications and some larger,

523
00:28:16,845 --> 00:28:19,215
real world codebases that she had.

524
00:28:19,508 --> 00:28:21,568
And she found that the results were mixed.

525
00:28:21,668 --> 00:28:27,171
She expected the compiler to optimize
fairly large percentages of the

526
00:28:27,171 --> 00:28:28,351
components in those codebases.

527
00:28:29,165 --> 00:28:32,985
And it only seemed to optimize
like 20 or 30 percent.

528
00:28:33,285 --> 00:28:37,258
Now, , apparently the compiler tool
does have a health check command

529
00:28:37,268 --> 00:28:41,511
that will tell you which components
it would bail out of because those

530
00:28:41,511 --> 00:28:43,381
are breaking the rules of React.

531
00:28:43,538 --> 00:28:48,991
And I believe that the updated React lint
rules can also give you an indication of

532
00:28:49,001 --> 00:28:50,941
which components might not get optimized.

533
00:28:51,298 --> 00:28:54,653
But her takeaway, I believe
her takeaway was You know what?

534
00:28:54,653 --> 00:28:58,673
Well, okay, like this, this seems
promising, but if real world code

535
00:28:58,673 --> 00:29:02,420
bases aren't going to get, or are we
going to have like 20 to 30 percent

536
00:29:02,490 --> 00:29:06,840
of the components improved, that's
not quite what we were pitched.

537
00:29:07,060 --> 00:29:10,570
Now, I will note that, uh, Satya from
the React, React compiler team, I

538
00:29:10,570 --> 00:29:14,276
believe commented here in Reactiflux
that, hey, this article is great.

539
00:29:14,286 --> 00:29:18,300
Like, we got to See these example apps
that she posted about, and we've been

540
00:29:18,300 --> 00:29:21,530
doing a bunch of additional changes to
make sure we're handling those cases.

541
00:29:21,633 --> 00:29:25,883
So, I mean, just because it didn't
work perfectly in her case, doesn't

542
00:29:25,883 --> 00:29:27,193
mean that the compiler's bust.

543
00:29:27,193 --> 00:29:29,313
It just means that it's
still a work in progress.

544
00:29:29,466 --> 00:29:32,056
So having that real world
feedback is actually very good.

545
00:29:32,296 --> 00:29:38,183
And then Tony Alicea, wrote an Excellent
article that actually breaks down what

546
00:29:38,183 --> 00:29:43,313
the compiler does and what the output
looks like and how it works in practice.

547
00:29:43,390 --> 00:29:45,900
So, very worth reading if you
want to understand what the

548
00:29:45,900 --> 00:29:47,370
compiler actually does for you.

549
00:29:47,640 --> 00:29:48,090
Carl Vitullo: Heck yeah.

550
00:29:48,376 --> 00:29:48,976
Cool.

551
00:29:49,466 --> 00:29:50,606
Yeah, I guess I'll move us on.

552
00:29:50,936 --> 00:29:55,863
I wanted to call out this There's been
a lot of, conversation that I've seen

553
00:29:55,933 --> 00:30:00,811
around, like, Laravel, specifically,
specifically Laravel, Theo put out

554
00:30:00,811 --> 00:30:04,850
a video that then somebody wrote a
blog post replying to of, " why don't

555
00:30:04,850 --> 00:30:06,610
we have a Laravel for JavaScript?"

556
00:30:06,834 --> 00:30:09,697
And this actually crossed my
radar from somebody who's not in

557
00:30:09,697 --> 00:30:14,369
the React world at all, they were
talking about scoping a project,

558
00:30:14,369 --> 00:30:16,839
adding authentication to some app.

559
00:30:17,059 --> 00:30:20,791
And they said, "this developer estimated
two weeks to add authentication to the

560
00:30:20,791 --> 00:30:22,591
product and I thought that was ridiculous.

561
00:30:22,591 --> 00:30:24,141
We have that out of the box in Laravel."

562
00:30:24,741 --> 00:30:28,408
I, I, I chimed in because it's like,
you know, I've done auth a couple of

563
00:30:28,438 --> 00:30:32,298
times in my life, in my career and
like, yeah, you know, okay, sure.

564
00:30:32,298 --> 00:30:36,443
A login form, that's not hard to do
in a day,  but when you get like a

565
00:30:36,453 --> 00:30:40,013
settings page and you know, you got to
be able to change your email address and

566
00:30:40,013 --> 00:30:44,353
reset your password and do two factor
authentication and, you know, social

567
00:30:44,353 --> 00:30:48,303
login, It's like, you know, I mean, two
weeks doesn't sound that wrong to me.

568
00:30:48,613 --> 00:30:52,755
And he replied like, All of this is, all
of that, everything you just described

569
00:30:52,755 --> 00:30:54,205
comes out of the box in Laravel.

570
00:30:54,655 --> 00:30:57,568
And it's like, alright, you
know what, okay, maybe we do

571
00:30:57,568 --> 00:30:58,758
complicate things a little bit.

572
00:30:58,885 --> 00:31:02,665
Maybe not overcomplicate, but I guess,
it, it, we do have so much flexibility

573
00:31:02,665 --> 00:31:08,305
and modularity and ability to Write things
from scratch in React and, you know,

574
00:31:08,305 --> 00:31:13,275
in the React ecosystem more broadly,
maybe that we have, you know, as far

575
00:31:13,275 --> 00:31:19,081
as the pendulum swings, maybe we have
stayed in maximum modularity mode for a

576
00:31:19,081 --> 00:31:20,751
little bit longer than might be optimal.

577
00:31:21,121 --> 00:31:21,471
I don't know.

578
00:31:21,491 --> 00:31:23,391
I, I'm curious what
you guys think of that.

579
00:31:23,391 --> 00:31:24,211
where's the trade off?

580
00:31:24,221 --> 00:31:27,911
Where's the optimal line
between modularity and out

581
00:31:27,911 --> 00:31:29,021
of the box functionality?

582
00:31:29,306 --> 00:31:29,561
I

583
00:31:29,561 --> 00:31:33,843
Mark Erikson: mean, I think a lot
of it also is the, you know, the

584
00:31:33,853 --> 00:31:35,523
whole back end, front end split.

585
00:31:35,730 --> 00:31:43,296
I mean, Laravel, you know, PHP, Rails,
Ruby, they are back end languages, and

586
00:31:43,306 --> 00:31:48,981
the use case is You know, like, you
know, the back end is doing basically

587
00:31:48,981 --> 00:31:51,661
all the work for you, and then, you
know, there, there might be some

588
00:31:51,661 --> 00:31:53,161
additional stuff on the front end.

589
00:31:53,405 --> 00:31:56,995
And so I think the frameworks there,
they've, they've been around longer,

590
00:31:57,121 --> 00:32:00,891
and also they evolved to have,
we, we need to have everything the

591
00:32:00,891 --> 00:32:03,611
back end needs to do all the work.

592
00:32:03,838 --> 00:32:09,431
Whereas, JS has always had the front
end, back end split, and it's not that

593
00:32:09,431 --> 00:32:13,431
we couldn't build something that was, you
know, absolutely out of the box like that.

594
00:32:13,431 --> 00:32:16,748
I mean, there are, you know, some
examples of that in the JS ecosystem,

595
00:32:17,028 --> 00:32:21,298
but I think it's typically been
much more of a, like, I just need

596
00:32:21,298 --> 00:32:23,911
a basic HTTP server like Express.

597
00:32:24,008 --> 00:32:27,625
to serve up my client side
code and then go from there.

598
00:32:27,675 --> 00:32:32,271
So, I think the modularity is a big
aspect, but then also the differences in,

599
00:32:32,281 --> 00:32:34,531
like, the ecosystem historically as well.

600
00:32:34,768 --> 00:32:37,535
Mo Khazali: I do think, you know,
I've spent a bit of time working

601
00:32:37,555 --> 00:32:40,605
in the Django world a little bit,
and I can definitely see the appeal

602
00:32:40,605 --> 00:32:44,145
to having something like Laravel,
where so much comes out of the box.

603
00:32:44,180 --> 00:32:44,970
Done for you.

604
00:32:45,010 --> 00:32:48,460
And that interconnectedness means
that it is a lot smoother to do things

605
00:32:48,460 --> 00:32:51,240
like you mentioned, like settings
on a profile to modify those things.

606
00:32:51,240 --> 00:32:53,460
They're all like one
centralized model in Django.

607
00:32:53,503 --> 00:32:56,773
And it's significantly easier to
create those sort of CRUD operations

608
00:32:56,783 --> 00:32:58,273
for users on like a settings page.

609
00:32:58,440 --> 00:32:59,400
It doesn't take you weeks.

610
00:32:59,400 --> 00:33:00,210
It takes you a day.

611
00:33:00,568 --> 00:33:03,638
And I know a lot of people who've been
developing a while, like they spent

612
00:33:03,648 --> 00:33:07,911
time in the PHP world or in the Python
world with Laravel or Django, and then

613
00:33:07,911 --> 00:33:10,501
they, you know, started doing React in
our company and they were all like, this

614
00:33:10,501 --> 00:33:12,351
sucks, really don't like doing this.

615
00:33:12,371 --> 00:33:15,671
It was so easy with Django, but I
guess it's the pendulum swings and we

616
00:33:15,671 --> 00:33:18,651
probably land on some sort of midpoint,
you know, I wouldn't be surprised if

617
00:33:18,651 --> 00:33:21,721
people start building things on top of
Next, which allows it to be a more full

618
00:33:21,741 --> 00:33:25,921
fledged opinionated server that also
can render and template React code.

619
00:33:26,271 --> 00:33:27,501
Mark Erikson: That's what Blitz was.

620
00:33:27,891 --> 00:33:32,605
Blitz started off as the whole
suite of things to go with Next,

621
00:33:32,605 --> 00:33:34,955
and then they tried to fork Next,
and then they gave up on that idea.

622
00:33:35,238 --> 00:33:37,551
Carl Vitullo: Yeah, and I mean,
I guess this is, over the last

623
00:33:37,561 --> 00:33:41,361
ten years, React has slowly, I
feel like it's grown in scope of,

624
00:33:41,371 --> 00:33:43,221
like, where people want to use it.

625
00:33:43,221 --> 00:33:48,061
Like, when I first started it, There was
a lot of, put it in, like, this spot, this

626
00:33:48,061 --> 00:33:51,691
little rectangle on the website, like,
that's where React goes, and several years

627
00:33:51,691 --> 00:33:56,964
ago, that moved into, most people are
using React to build their entire app,

628
00:33:56,994 --> 00:34:02,681
like it owns the entire client side, and
now we're moving Up the chain into React

629
00:34:02,771 --> 00:34:04,811
owns more of the server side as well.

630
00:34:05,048 --> 00:34:09,095
So maybe that's just kind of like the,
this projects like Laravel already

631
00:34:09,105 --> 00:34:11,195
owned the data model in the server.

632
00:34:11,344 --> 00:34:15,011
And they had to come from there into
owning more of the client side to

633
00:34:15,011 --> 00:34:16,561
provide a better experience there.

634
00:34:16,861 --> 00:34:21,258
And they certainly don't compete with
React there in any meaningful way.

635
00:34:21,258 --> 00:34:25,428
Like nobody would, I don't think anyone
would seriously suggest that projects

636
00:34:25,428 --> 00:34:28,568
like Laravel are able to provide.

637
00:34:28,860 --> 00:34:34,991
An exact, or a highly comparable,
interactive client side experience.

638
00:34:35,451 --> 00:34:37,181
You know, as I'm saying that,
nobody would argue that.

639
00:34:37,181 --> 00:34:39,311
I think DHH has seriously argued that.

640
00:34:39,821 --> 00:34:42,231
Mo Khazali: I was gonna say
DHH hasn't argued that yet.

641
00:34:42,371 --> 00:34:45,597
Carl Vitullo: So, okay, people do
People do argue that, but let me

642
00:34:45,597 --> 00:34:47,807
add the caveat of offline capable.

643
00:34:48,087 --> 00:34:52,527
I don't think anyone would seriously argue
they provide an offline capable client

644
00:34:52,527 --> 00:34:54,677
side experience comparable to React.

645
00:34:54,730 --> 00:34:59,520
And so, yeah, I guess, you know, now with,
as server components expand in utility

646
00:34:59,520 --> 00:35:04,752
and capabilities, like, yeah, maybe we
will start seeing more of a Laravel.

647
00:35:04,827 --> 00:35:09,877
Or Ruby on Rails type of full
ownership of the experience,

648
00:35:10,137 --> 00:35:11,467
which would make it more easy.

649
00:35:11,627 --> 00:35:15,587
Because that's really the problem
here is React isn't even aware of

650
00:35:15,587 --> 00:35:18,057
the data model in most applications.

651
00:35:18,395 --> 00:35:20,898
So that makes it very hard to
do CRUD  interactions, if you

652
00:35:20,898 --> 00:35:23,588
don't have the data, if you don't
have direct access to the data.

653
00:35:23,638 --> 00:35:26,328
I just thought that was a really
interesting framing for this.

654
00:35:26,378 --> 00:35:29,628
Like I have all, I've, I've lived
in React for many, many years.

655
00:35:29,798 --> 00:35:34,388
And so then seeing people talk about
how quickly you can do common tasks

656
00:35:34,388 --> 00:35:36,233
in a Laravel, it's like, Oh, Shit.

657
00:35:36,413 --> 00:35:36,963
Interesting.

658
00:35:37,213 --> 00:35:38,573
That's, that is a big difference.

659
00:35:39,063 --> 00:35:39,413
Cool.

660
00:35:39,443 --> 00:35:43,323
Let's move on to Vercel Ship,
their conference roundup.

661
00:35:43,433 --> 00:35:44,633
Moe, do you want to take us on that?

662
00:35:45,133 --> 00:35:45,463
Mo Khazali: Sure.

663
00:35:45,543 --> 00:35:48,823
just the general and quickly running
through this, Vercel is obviously

664
00:35:48,823 --> 00:35:52,223
moving across and, and taking
up more of the, more than just

665
00:35:52,253 --> 00:35:54,023
becoming a hosting platform, so.

666
00:35:54,388 --> 00:35:57,098
There's pieces on how you can
collaborate and people in different

667
00:35:57,098 --> 00:35:59,908
teams can collaborate and, you know,
preview different sort of webpages.

668
00:35:59,908 --> 00:36:02,828
And we've seen some stuff like that
and more focus on observability.

669
00:36:03,148 --> 00:36:05,528
So they've added things like
metrics and feature flags.

670
00:36:05,808 --> 00:36:08,648
And so there was someone who actually
commented on Twitter about how

671
00:36:08,648 --> 00:36:11,228
beautiful their toolbar was as well,
which I thought was quite cool.

672
00:36:11,448 --> 00:36:13,518
But no, there's, there's like
a lot of direction around like

673
00:36:13,758 --> 00:36:17,308
product collaboration and a push
in that, in, in that direction.

674
00:36:17,658 --> 00:36:18,888
So that's quite interesting.

675
00:36:18,898 --> 00:36:21,318
Just on the observability piece, I
actually found it quite interesting that

676
00:36:21,348 --> 00:36:23,138
hosting providers are going in that space.

677
00:36:23,228 --> 00:36:27,488
So Cloudflare a few months ago acquired
Baseline, which is also an observability

678
00:36:27,488 --> 00:36:30,778
tool, and I think they're trying to
integrate it into their workers slash

679
00:36:30,788 --> 00:36:34,558
Cloudflare pages space, which is a
competitor to Vercel's, you know,

680
00:36:34,568 --> 00:36:37,748
hosting platform plus their, their
serverless functions that they've got.

681
00:36:37,995 --> 00:36:39,635
So, or the edge functions
that they've got.

682
00:36:39,842 --> 00:36:41,832
So I think it's interesting
that a lot of them are moving.

683
00:36:42,055 --> 00:36:44,755
Past just hosting into that
observability space as well.

684
00:36:44,755 --> 00:36:46,665
And I think there's going to be
a pretty big competition in that

685
00:36:46,665 --> 00:36:48,168
space in the next couple of years.

686
00:36:48,168 --> 00:36:48,798
Carl Vitullo: Okay.

687
00:36:48,798 --> 00:36:50,278
That makes sense.

688
00:36:50,578 --> 00:36:50,818
Yeah.

689
00:36:50,818 --> 00:36:54,968
I haven't yet played with this at all,
but I think I've heard people discussing

690
00:36:54,978 --> 00:36:59,720
the Vercel, metrics and feature flagging
and that, yeah, I think that the, tacking

691
00:36:59,720 --> 00:37:04,403
those onto the, to a hosting provider does
make a lot of sense to me because I feel

692
00:37:04,403 --> 00:37:08,003
like you get, you start getting a lot more
things for free if those are all bundled

693
00:37:08,003 --> 00:37:11,617
together into one thing, like, I don't
know, just having used LaunchDarkly and

694
00:37:11,617 --> 00:37:13,937
other feature flagging tools like that.

695
00:37:14,327 --> 00:37:18,120
It feels like if they knew when
a release was happening, if those

696
00:37:18,130 --> 00:37:22,450
feature flagging tools knew when a
release was happening, I can imagine

697
00:37:22,513 --> 00:37:28,330
various optimizations or improvements
to the, like, developer experience,

698
00:37:28,360 --> 00:37:32,347
the experience of putting out a new
release that could be enabled by that.

699
00:37:32,357 --> 00:37:34,257
So yeah, that's something
I'm paying attention to.

700
00:37:34,547 --> 00:37:35,277
We'll see how that goes.

701
00:37:35,707 --> 00:37:39,480
Mark Erikson: All right,
next up, TypeScript 5.

702
00:37:39,480 --> 00:37:40,980
5 is out.

703
00:37:40,980 --> 00:37:44,680
And the, the single biggest thing that
is interesting about this release is what

704
00:37:44,680 --> 00:37:47,570
they're calling inferred Type predicates.

705
00:37:47,650 --> 00:37:50,161
So as a little bit of background,
one of the nifty things about

706
00:37:50,161 --> 00:37:55,082
TypeScript is you can write code that
does runtime checks, and TypeScript

707
00:37:55,092 --> 00:38:00,656
uses that to narrow down TypeScript
type of a particular variable is.

708
00:38:00,805 --> 00:38:04,845
And part of that is not just having
like an if statement, but actually

709
00:38:04,855 --> 00:38:10,895
having separate functions that, for
example, accept any value, and then

710
00:38:10,895 --> 00:38:15,305
they do some runtime checks and you tell
TypeScript, if this function returns

711
00:38:15,315 --> 00:38:21,959
true, then the actual TS type of the
value must be some more specific type.

712
00:38:22,160 --> 00:38:25,610
And so you can use that to tie
together runtime checks and

713
00:38:25,669 --> 00:38:27,258
type and compile time behavior.

714
00:38:27,649 --> 00:38:32,836
But the issue was that things like filter
callbacks for arrays, which return a

715
00:38:32,836 --> 00:38:36,177
boolean, didn't do any of that narrowing.

716
00:38:36,187 --> 00:38:40,002
And so you might have, like, an
array that could be, like, item

717
00:38:40,012 --> 00:38:42,480
or null, and you could do a check.

718
00:38:42,690 --> 00:38:47,117
In the filter callback and say, if
thing is not null, you know, return

719
00:38:47,117 --> 00:38:50,990
true, which ought to tell you that
by the time we're done, we only

720
00:38:50,990 --> 00:38:53,134
have actual items and no nulls.

721
00:38:53,644 --> 00:38:57,994
But TypeScript wouldn't automatically
narrow down the TS types based

722
00:38:57,994 --> 00:38:59,886
on callback functions like that.

723
00:39:00,189 --> 00:39:02,024
So with TypeScript 5.

724
00:39:02,024 --> 00:39:04,359
5, they've improved the type inference.

725
00:39:04,452 --> 00:39:10,523
So that if you have a function that
accepts some value and does some checks

726
00:39:10,573 --> 00:39:15,735
and returns a boolean, TypeScript will
automatically try to narrow down the

727
00:39:15,745 --> 00:39:18,227
TS types of the output to be stricter.

728
00:39:18,575 --> 00:39:22,755
And so, this is going to be a nice
little quality of life improvement for

729
00:39:22,765 --> 00:39:24,995
a lot of different TypeScript use cases.

730
00:39:25,263 --> 00:39:28,588
One other interesting thing that
I saw in there, is that apparently

731
00:39:28,588 --> 00:39:32,198
they're doing some syntax
checking on regular expressions.

732
00:39:32,396 --> 00:39:34,646
Mostly just catching things
like, you know, like you have

733
00:39:34,646 --> 00:39:36,526
too many parentheses in there.

734
00:39:36,771 --> 00:39:38,512
But that one's actually pretty cool too.

735
00:39:38,771 --> 00:39:40,161
Carl Vitullo: Yeah, definitely super cool.

736
00:39:40,191 --> 00:39:43,933
I, on my list of things that I, that
would make me excited, like typescript

737
00:39:43,963 --> 00:39:47,745
checking regexes was not on there,
so I, Very unexpected for them to

738
00:39:47,745 --> 00:39:49,485
even start moving in that direction.

739
00:39:49,485 --> 00:39:53,695
But like, heck yeah, please help me
make my regexes a little more robust.

740
00:39:54,175 --> 00:39:57,145
Mark Erikson: One other thing towards
the bottom that's under the hood.

741
00:39:57,360 --> 00:40:02,640
So they've done some changes on
their internal variable definitions.

742
00:40:02,834 --> 00:40:07,494
So that they get more optimized by the
JavaScript runtime, basically making

743
00:40:07,494 --> 00:40:10,604
sure that the same fields always exist.

744
00:40:10,719 --> 00:40:15,259
And you don't like occasionally add an
extra field to the object dynamically.

745
00:40:15,259 --> 00:40:19,129
And so because of that, the runtimes
are able to optimize the behavior.

746
00:40:19,293 --> 00:40:23,903
And they found that it actually improved
compile times by like 5 to 10 percent

747
00:40:24,003 --> 00:40:26,203
just by making the fields more consistent.

748
00:40:26,424 --> 00:40:30,664
Carl Vitullo: Yeah, I also want to
share, Matt Pocock did a really great,

749
00:40:30,744 --> 00:40:35,252
just like quick 10 minute video breaking
down what's new in TypeScript 5.

750
00:40:35,252 --> 00:40:35,256
5.

751
00:40:35,257 --> 00:40:39,240
So definitely worth, he's just
such a great TypeScript expert.

752
00:40:39,280 --> 00:40:40,230
Just wanted to call that out.

753
00:40:40,340 --> 00:40:40,850
Great resource.

754
00:40:41,250 --> 00:40:41,600
Cool.

755
00:40:41,620 --> 00:40:45,760
I wanted to shout out a conference
talk by Ryan Florence that

756
00:40:45,760 --> 00:40:47,580
came out of Big Sky DevCon.

757
00:40:47,910 --> 00:40:51,510
I saw quite a number of people
referring to it as like the

758
00:40:51,510 --> 00:40:53,870
best talk I've seen in years.

759
00:40:54,730 --> 00:40:56,400
I don't know if I would
go that far personally.

760
00:40:56,400 --> 00:40:57,520
It's a great, it is a great talk.

761
00:40:57,530 --> 00:41:00,670
It's, it's kind of just, I think I
would describe it as like an oral

762
00:41:00,670 --> 00:41:06,630
history of the Problem space that React
Server Components is trying to address.

763
00:41:06,670 --> 00:41:09,510
It just sort of talks about like the
difference between, you know, the

764
00:41:09,510 --> 00:41:14,330
server and the client and the network
being in the middle and plots out a

765
00:41:14,330 --> 00:41:19,091
couple of different tools and where
they live in that, You know, taxonomy.

766
00:41:19,288 --> 00:41:20,428
Definitely worth checking out.

767
00:41:20,498 --> 00:41:23,168
I mean, Ryan Florence has
been around for so, so long.

768
00:41:23,208 --> 00:41:28,922
So hearing him just do kind of a
dump of history of a problem, I

769
00:41:29,112 --> 00:41:30,042
thought was really interesting.

770
00:41:30,322 --> 00:41:32,386
It was definitely worth listening to.

771
00:41:33,112 --> 00:41:36,126
Mo Khazali: I'll jump in with
some React Native stuff quickly.

772
00:41:36,196 --> 00:41:40,883
So first, and I'd say most significant
news in this space is unfortunately

773
00:41:40,883 --> 00:41:46,793
that Lorenzo Sciandra from the Microsoft
team is leaving the React Native world

774
00:41:46,823 --> 00:41:50,146
and also leaving Microsoft, which
is, I would say personally, a pretty

775
00:41:50,146 --> 00:41:51,946
big blow to this, to this community.

776
00:41:51,956 --> 00:41:54,366
He's been such an instrumental part of.

777
00:41:54,580 --> 00:41:57,010
Getting more and more community
involvement inside of React Native.

778
00:41:57,010 --> 00:41:59,680
He's been doing React Native
for more than six years and,

779
00:41:59,700 --> 00:42:01,270
you know, being based in the UK.

780
00:42:01,300 --> 00:42:05,636
I've known him personally for a couple
of years now and such a lovely guy.

781
00:42:05,666 --> 00:42:09,123
And I think he's moving on to focus
something around making sure that

782
00:42:09,123 --> 00:42:12,248
the tech space is A little bit
healthier and a little bit more

783
00:42:12,311 --> 00:42:13,781
humane, as he likes to put it.

784
00:42:13,981 --> 00:42:17,401
And he's been focusing on mental health
struggles within the tech ecosystem

785
00:42:17,401 --> 00:42:19,521
and within, within a career of tech.

786
00:42:19,621 --> 00:42:22,301
So you should definitely check
out his podcast called Debug Mind.

787
00:42:22,338 --> 00:42:25,068
But really just want to, from the
bottom of my heart, say a big thank

788
00:42:25,068 --> 00:42:27,738
you to Lorenzo for everything that
he's done over the last six plus years.

789
00:42:27,958 --> 00:42:31,158
An absolute shame that he's leaving us,
but I am very excited for everything

790
00:42:31,158 --> 00:42:32,598
that he's going to be doing afterwards.

791
00:42:33,113 --> 00:42:37,753
Carl Vitullo: Yeah, I have repeatedly
come across his name when I've

792
00:42:37,753 --> 00:42:39,523
looked for React Native resources.

793
00:42:39,603 --> 00:42:44,010
He's done so many great lists of like,
I can't even remember the various types

794
00:42:44,010 --> 00:42:48,820
of lists he's done, but just like major
projects in the React Native space and

795
00:42:48,830 --> 00:42:51,215
educational resources on React Native.

796
00:42:51,505 --> 00:42:55,385
Yeah, definitely a big blow to
have him exit the ecosystem.

797
00:42:55,875 --> 00:42:58,485
Mo Khazali: And, you know, more
than that, you know, I think Lorenzo

798
00:42:58,485 --> 00:43:01,365
has been sort of the person who's
been trying to bring the meta team

799
00:43:01,395 --> 00:43:03,045
closer and closer to the community.

800
00:43:03,305 --> 00:43:06,790
So, you know, Lorenzo, for the first
time that I went to Meta's offices,

801
00:43:06,790 --> 00:43:10,097
Lorenzo invited me and, Organize that
with a lot of the Meta folks to, to

802
00:43:10,107 --> 00:43:12,477
bring me over and, you know, for me to
be able to chat and bring some of my

803
00:43:12,477 --> 00:43:15,307
concerns over to some of the folks at
Meta and, you know, that became more of

804
00:43:15,307 --> 00:43:16,917
a recurring thing, all thanks to Lorenzo.

805
00:43:17,267 --> 00:43:19,767
So he's been very instrumental and
he's one of those sort of open source

806
00:43:19,767 --> 00:43:22,327
maintainer that maintainers that
really cares about the community.

807
00:43:22,677 --> 00:43:23,917
So yeah, definitely a big blow.

808
00:43:24,117 --> 00:43:28,187
Carl Vitullo: Yeah, and earlier,
Mark was talking about how the React

809
00:43:28,187 --> 00:43:31,787
Native team has been a little bit
better than the React core team at

810
00:43:32,107 --> 00:43:35,777
interfacing, doing like working groups
and things like that, and including

811
00:43:35,787 --> 00:43:36,957
the community and the development.

812
00:43:36,967 --> 00:43:39,737
I wonder, I wonder what role he
played in making that happen.

813
00:43:40,217 --> 00:43:41,387
Mo Khazali: A major one, definitely.

814
00:43:41,417 --> 00:43:42,327
So, yeah, but.

815
00:43:42,737 --> 00:43:43,527
Best of luck to him.

816
00:43:43,557 --> 00:43:46,457
I'm sure he's got some amazing stuff lined
up that he's going to be exploring next.

817
00:43:46,457 --> 00:43:47,067
And yeah.

818
00:43:47,187 --> 00:43:50,827
Next up, one thing that I'm personally
super excited about is Expo Atlas.

819
00:43:51,029 --> 00:43:55,791
So Expo Atlas is almost like a sort
of bundle size visualizer, but taken

820
00:43:55,791 --> 00:43:57,651
to a little bit of a higher level.

821
00:43:57,941 --> 00:43:59,921
And this is something that's
been missing from the React

822
00:43:59,921 --> 00:44:01,321
Native ecosystem for a long time.

823
00:44:01,321 --> 00:44:02,761
So just a little bit of context.

824
00:44:02,961 --> 00:44:07,081
Bundle size has never been a concern for
the React Native ecosystem, unfortunately.

825
00:44:07,091 --> 00:44:11,051
For, for, for better or for worse,
because it's all sort of sent once in

826
00:44:11,051 --> 00:44:13,935
the bundle of an application, when you
download it from the app store, people

827
00:44:13,935 --> 00:44:17,622
don't seem to really care that much
about how much JavaScript you ship, so

828
00:44:17,622 --> 00:44:19,302
long as it's downloaded once it's done.

829
00:44:19,342 --> 00:44:22,841
And, you know, things like app startup
time and actually, you know, having a lot

830
00:44:22,841 --> 00:44:26,931
of JavaScript and runtime don't affect
React Native apps as much because of.

831
00:44:27,037 --> 00:44:30,587
Things like Hermes existing, where you
have an engine that will have some sort

832
00:44:30,587 --> 00:44:33,877
of like bytecode representation and
not have to load the entire JavaScript

833
00:44:33,901 --> 00:44:35,561
bundle into, into its runtime.

834
00:44:35,911 --> 00:44:40,081
So that's been a challenge when
you're trying to take React Native

835
00:44:40,081 --> 00:44:42,841
and put it on the web and deal
with this whole universal story.

836
00:44:42,888 --> 00:44:46,138
And so, you know, one of the things
that I spent a lot of time around React

837
00:44:46,138 --> 00:44:49,758
Summit, speaking to Evan and Cedric
from the Expo team about was, you

838
00:44:49,758 --> 00:44:52,588
know, how do we make sure that some of
the third party libraries that have.

839
00:44:52,756 --> 00:44:55,886
I've been creating over a long period
of time in the React Native ecosystem,

840
00:44:55,911 --> 00:44:58,871
actually have small bundle sizes
when you try to take them to the web.

841
00:44:59,161 --> 00:45:03,111
And Expo Atlas is kind of the take that
the Expo team has at doing that, which

842
00:45:03,121 --> 00:45:06,861
is, well, a lot of these libraries are
all CJS based, so if we just introduce

843
00:45:06,871 --> 00:45:10,284
tree shaking into the bundler for React
Native, It's not going to necessarily

844
00:45:10,284 --> 00:45:13,434
solve that problem by itself because most
of the libraries won't be tree shakable.

845
00:45:13,507 --> 00:45:14,847
So then what's the way to do it?

846
00:45:14,867 --> 00:45:17,855
Well, let's just visualize the problem,
see what libraries are bundling in

847
00:45:17,855 --> 00:45:21,775
a lot of crap, and then see if we
can slowly start to, as a community,

848
00:45:21,775 --> 00:45:24,966
shave some of that off and improve the
performance for React Native web apps.

849
00:45:25,256 --> 00:45:26,266
This is a slow burn.

850
00:45:26,313 --> 00:45:27,273
It's not going to.

851
00:45:27,302 --> 00:45:30,232
Change over the next year, two years,
maybe even three years, because

852
00:45:30,232 --> 00:45:31,352
there's a lot of legacy there.

853
00:45:31,469 --> 00:45:32,419
But I think it's the right step.

854
00:45:32,539 --> 00:45:34,229
It's showing and visualizing the problem.

855
00:45:34,239 --> 00:45:35,829
So great tool that's out there.

856
00:45:35,839 --> 00:45:36,749
We'd definitely check it out.

857
00:45:36,929 --> 00:45:40,269
It shows you in a different way to
how like the bundle visualizers that

858
00:45:40,269 --> 00:45:43,943
you might be used to, it actually
shows you which import of a library

859
00:45:43,943 --> 00:45:48,611
you have in your code that is actually
causing this library that might be

860
00:45:48,611 --> 00:45:50,202
bloating your bundle to be loaded.

861
00:45:50,212 --> 00:45:53,142
So, you know, it might, it goes down
the tree for transitive dependencies

862
00:45:53,142 --> 00:45:54,212
as well, which is quite cool.

863
00:45:54,465 --> 00:45:56,075
Mark Erikson: Oh, that's wonderful.

864
00:45:56,293 --> 00:45:57,173
Mo Khazali: Really great tool.

865
00:45:57,348 --> 00:45:57,608
Carl Vitullo: Yeah.

866
00:45:57,608 --> 00:46:00,878
I'm looking at this, the visualization
of the blog post with the, you

867
00:46:00,878 --> 00:46:05,528
know, recursive squares showing
the, the bundle size and, oh man, I

868
00:46:05,528 --> 00:46:09,988
remember almost a visually, almost
identical tool, much less polished.

869
00:46:10,398 --> 00:46:14,646
Clearly this has someone who did a
design pass, but there was a very

870
00:46:14,646 --> 00:46:18,476
similar tool that came out for
Webpack in like, I don't know, 2014.

871
00:46:19,336 --> 00:46:23,561
Mark Erikson: There's been a number of
them, Webpack Bundle Analyzer, Source

872
00:46:23,561 --> 00:46:24,711
Map Explorer, and a couple others.

873
00:46:25,236 --> 00:46:29,246
Carl Vitullo: I, I like practically made
a career out of like fixing performance

874
00:46:29,276 --> 00:46:33,386
issues just because I learned that tool
and it actually enabled me to do things.

875
00:46:33,916 --> 00:46:34,886
So yeah, cool.

876
00:46:34,896 --> 00:46:35,506
Love to see it.

877
00:46:35,506 --> 00:46:37,176
Love to see it in the
React Native context.

878
00:46:37,216 --> 00:46:38,126
Definitely looks valuable.

879
00:46:38,473 --> 00:46:38,923
Mo Khazali: Cool.

880
00:46:39,024 --> 00:46:40,924
So then a few sort of quick things.

881
00:46:40,964 --> 00:46:43,504
Firstly, Expo's now added
React compiler support.

882
00:46:43,534 --> 00:46:45,049
We saw this in the React Conf app.

883
00:46:45,279 --> 00:46:46,839
It was already using the React compiler.

884
00:46:46,929 --> 00:46:50,009
So just, you know, if you want
to try it out experimentally, you

885
00:46:50,009 --> 00:46:52,259
can use the React compiler and
see how it works for your app.

886
00:46:52,729 --> 00:46:56,279
Next up is Starlink's React Native story.

887
00:46:56,299 --> 00:46:58,989
So this was interesting because
it came out during AppJS,

888
00:46:59,029 --> 00:47:00,039
which happened last month.

889
00:47:00,229 --> 00:47:03,509
So the Starlink app is, is obviously
built with React Native and it

890
00:47:03,509 --> 00:47:07,349
uses a lot of the expo libraries
and things like React 3 Fiber.

891
00:47:07,516 --> 00:47:10,386
And it's really cool to see how
some of these tools that we all have

892
00:47:10,386 --> 00:47:13,816
available to us are used in practice
in some pretty serious production apps.

893
00:47:14,012 --> 00:47:17,197
And then another quick fire
one, minor changes to Expo

894
00:47:17,197 --> 00:47:19,167
Router in Expo Router version 3.

895
00:47:19,207 --> 00:47:19,687
5.

896
00:47:19,884 --> 00:47:23,215
So, just some stuff like,
you know, supporting the, the

897
00:47:23,215 --> 00:47:25,055
sort of the hash parameters.

898
00:47:25,151 --> 00:47:28,301
There's some stuff around native,
native intents with deep linking that

899
00:47:28,301 --> 00:47:32,241
you'll need for having a more seamless
handoff between different Devices, and

900
00:47:32,241 --> 00:47:36,510
also for allowing for certain links
to, to come with more details to, to

901
00:47:36,530 --> 00:47:38,550
really augment the native functionality.

902
00:47:38,760 --> 00:47:41,730
Another small thing that I think
is quite important, that's not

903
00:47:41,730 --> 00:47:45,113
actually one of the top headlines
with this, is that previously Expo

904
00:47:45,123 --> 00:47:49,063
router was using an, a non standard
version of the request and response.

905
00:47:49,153 --> 00:47:52,063
And with this version, they've,
they've standardized it a bit

906
00:47:52,063 --> 00:47:54,883
more, which is great because that
should definitely be standardized.

907
00:47:55,243 --> 00:47:56,243
And then a few.

908
00:47:56,313 --> 00:47:58,563
Other minor things that I'm
just going to run through.

909
00:47:58,853 --> 00:48:02,863
One is React Native Vision OS
won the Git Nation Open Source

910
00:48:02,883 --> 00:48:04,483
Award, which was quite cool.

911
00:48:04,483 --> 00:48:05,543
It's a really cool project.

912
00:48:05,563 --> 00:48:06,413
Definitely give it a shot.

913
00:48:06,433 --> 00:48:09,335
And the folks from Callstack were
there at a bunch of these different

914
00:48:09,335 --> 00:48:12,845
conferences with Apple Vision pros,
trying to get people to try out

915
00:48:12,885 --> 00:48:16,045
React Native with Vision OS, which
was quite a fun thing to try out.

916
00:48:16,570 --> 00:48:18,690
Next up there is sf symbols.

917
00:48:18,690 --> 00:48:23,310
So sf symbols is sort of an icon
pack that comes default with iOS.

918
00:48:23,370 --> 00:48:28,840
It oftentimes feels very Apple esque and
having that inside of your app means that

919
00:48:28,870 --> 00:48:33,790
the icons are uniform with the OS and they
look and feel like it's an iOS application

920
00:48:34,100 --> 00:48:36,540
and Expo's added beta support for it.

921
00:48:36,740 --> 00:48:40,891
This is an interesting one because React
Native is obviously cross platform.

922
00:48:41,057 --> 00:48:44,879
The main targets that you'll have is an
iOS and an Android app, so specifically

923
00:48:44,879 --> 00:48:49,812
supporting icon sets and an icon set
that's available for iOS means that

924
00:48:49,812 --> 00:48:52,402
you may need to have some divergence
in your code base if you want to

925
00:48:52,402 --> 00:48:56,927
really use those SF symbols, and you'll
need to create or choose equivalent

926
00:48:57,007 --> 00:49:00,428
Android icons, so a little bit of an
odd take, but I'll see you A lot of

927
00:49:00,438 --> 00:49:03,758
people seem to really want to use SF
Symbols, even with React Native apps.

928
00:49:03,798 --> 00:49:07,469
So I'm sure that there was a level
of feature requests and community

929
00:49:07,469 --> 00:49:09,059
involvement in trying to get that working.

930
00:49:09,169 --> 00:49:10,399
So that's definitely there.

931
00:49:10,909 --> 00:49:12,879
And then lastly, React Native Screens.

932
00:49:12,919 --> 00:49:16,339
This is actually a library that
you will rarely ever have to use

933
00:49:16,499 --> 00:49:19,629
directly inside of your application
code, but it's actually being used

934
00:49:19,769 --> 00:49:22,939
under the hood by React Navigation,
which is by far the most common

935
00:49:23,199 --> 00:49:25,599
navigation library within React Native.

936
00:49:25,819 --> 00:49:29,039
And they've just added some
extra minor improvements.

937
00:49:29,109 --> 00:49:31,917
One that's quite cool is
transparent header support.

938
00:49:31,987 --> 00:49:35,270
Obviously on the native layer, there's
functionalities on iOS and Android to

939
00:49:35,270 --> 00:49:38,180
be able to add a transparent heading
that's got a little bit of a blur, and

940
00:49:38,180 --> 00:49:39,600
it comes up with some cool effects.

941
00:49:39,725 --> 00:49:43,345
You can do that in React Native with the,
with the default navigation libraries.

942
00:49:43,415 --> 00:49:47,265
So React Native Screens has been updated
to support that on both iOS and Android

943
00:49:47,265 --> 00:49:49,305
now, which is just cool minor changes.

944
00:49:49,699 --> 00:49:51,969
And that's just about everything
that's been happening in the React

945
00:49:51,969 --> 00:49:53,369
Native ecosystem in the last month.

946
00:49:53,860 --> 00:49:54,320
Carl Vitullo: Nice.

947
00:49:54,550 --> 00:49:54,960
Excellent.

948
00:49:54,970 --> 00:49:56,090
Thank you for catching us up.

949
00:49:56,330 --> 00:49:59,054
Okay, shall we move on to our
lightning round, see how many

950
00:49:59,054 --> 00:49:59,874
links we can get through there?

951
00:50:00,694 --> 00:50:03,544
Mark Erikson: Yes, because we're already
an hour in, so moving right along.

952
00:50:03,944 --> 00:50:08,624
I saw a really, really cool tool
called React Internals Explorer.

953
00:50:08,684 --> 00:50:12,234
It looks like you write some
React code in a sandbox editor.

954
00:50:12,469 --> 00:50:16,519
And then it actually digs into
the React fiber tree and shows

955
00:50:16,519 --> 00:50:17,529
you the structures of that.

956
00:50:17,782 --> 00:50:20,712
I haven't even had time to play
with this, but just like glancing

957
00:50:20,712 --> 00:50:22,242
at it and seeing a screenshot.

958
00:50:22,519 --> 00:50:25,059
I'm actually really, really
excited about this because I love

959
00:50:25,059 --> 00:50:26,949
digging inside React's internals.

960
00:50:26,949 --> 00:50:30,039
I know most other people don't need
to, but this looks really helpful.

961
00:50:30,345 --> 00:50:33,505
And the author has already written a
whole series of blog posts where they

962
00:50:33,505 --> 00:50:38,265
actually go straight into the React source
code and explain how specific features

963
00:50:38,285 --> 00:50:40,875
of React are implemented under the hood.

964
00:50:41,119 --> 00:50:44,459
So if you want to know how React
works inside, very worth reading.

965
00:50:44,959 --> 00:50:45,179
Carl Vitullo: Yeah.

966
00:50:45,179 --> 00:50:49,092
I wanted to call out a blog
post from the Chrome team where

967
00:50:49,092 --> 00:50:51,205
they just, they do a recap.

968
00:50:51,205 --> 00:50:54,085
What's new in JavaScript
frameworks for May, 2024.

969
00:50:54,085 --> 00:50:55,665
So this is, I guess this is old.

970
00:50:55,665 --> 00:50:56,405
It's undated.

971
00:50:56,482 --> 00:51:00,362
So I guess it must have come out
last month, but they are just, they

972
00:51:00,362 --> 00:51:02,322
just quickly round up a bunch of.

973
00:51:02,722 --> 00:51:06,512
they go through like Angular,
Astro, React, Remix, Next, Vue, NUC,

974
00:51:07,032 --> 00:51:09,202
Solidsfelt, and a couple of others.

975
00:51:09,322 --> 00:51:09,512
Yeah.

976
00:51:09,512 --> 00:51:12,112
This is Adi Osmani is.

977
00:51:12,847 --> 00:51:17,047
One of the, you know, it looked like they
did a video and wrote a blog post with it.

978
00:51:17,467 --> 00:51:21,477
I thought it was curious, or I thought
it was interesting to see what the Chrome

979
00:51:21,507 --> 00:51:24,297
team thinks about JavaScript frameworks.

980
00:51:24,923 --> 00:51:27,043
Mark Erikson: There were a few
different blog posts that touched

981
00:51:27,043 --> 00:51:28,853
on the theme of memory leaks.

982
00:51:28,918 --> 00:51:34,418
There was one that talked about memory
leaks inside of Node, potentially

983
00:51:34,418 --> 00:51:39,048
if you're using the relatively
new local async storage feature.

984
00:51:39,501 --> 00:51:42,111
the example there was with setTimeout.

985
00:51:42,191 --> 00:51:46,391
Apparently, Node can be keeping track
of async call stacks attached to the

986
00:51:46,391 --> 00:51:51,200
context storage, and so you could actually
end up leaking a whole bunch of memory

987
00:51:51,330 --> 00:51:53,030
if you're using it in certain ways.

988
00:51:53,359 --> 00:51:56,539
Uh, similarly, there are also a couple
of very good blog posts talking about

989
00:51:56,539 --> 00:52:00,529
potential ways you might end up with
memory leaks in a React application.

990
00:52:00,812 --> 00:52:06,124
In cases where you're using like use
callback or use memo or with React query

991
00:52:06,389 --> 00:52:10,859
where you're writing functions that
are doing data fetching or something

992
00:52:10,859 --> 00:52:14,879
like that, and they're closing over
variables that are in scope and

993
00:52:15,029 --> 00:52:16,649
they might not even be getting used.

994
00:52:16,985 --> 00:52:20,915
But the closure keeps those variables
alive longer than you would have expected.

995
00:52:21,425 --> 00:52:21,815
Mo Khazali: Cool.

996
00:52:22,325 --> 00:52:26,305
So next up is an article that's
actually on Martin Fowler's blog.

997
00:52:26,325 --> 00:52:31,085
So Martin Fowler being the big thought
leader and evangelist of, of all

998
00:52:31,095 --> 00:52:33,425
things, application development, period.

999
00:52:33,515 --> 00:52:35,775
Mark Erikson: Enterprise
architecture patterns.

1000
00:52:35,875 --> 00:52:39,685
Mo Khazali: You see, divisive at the
best of times, Martin Fowler is, but

1001
00:52:39,745 --> 00:52:42,965
there's, there's been more and more
React articles popping on, and they're

1002
00:52:42,965 --> 00:52:46,495
not actually written by Martin Fowler,
but they're written by someone who works

1003
00:52:46,575 --> 00:52:49,855
at, whose name is Juntao, or actually,
I don't think he works at ThoughtWorks,

1004
00:52:50,105 --> 00:52:53,415
but he's very close with Martin Fowler,
so he writes on Martin Fowler's blogs.

1005
00:52:53,785 --> 00:52:57,715
And he's been doing some really cool
work on writing articles that start from

1006
00:52:57,715 --> 00:53:02,545
the basic principles and expand out and
create more and more complex applications

1007
00:53:02,545 --> 00:53:03,905
that explain a bunch of concepts.

1008
00:53:03,962 --> 00:53:06,682
So his latest article is about data
fetching patterns in single page

1009
00:53:06,682 --> 00:53:10,545
applications, and it starts with basic
React concepts, builds up around, you

1010
00:53:10,545 --> 00:53:14,705
know, asynchronous states being handled on
the client side, parallel data fetching,

1011
00:53:14,745 --> 00:53:17,879
how do you handle fallbacks, and then
things like pre fetching, and then kind

1012
00:53:17,879 --> 00:53:21,547
of It takes you through this journey and
tells you when you should use which one.

1013
00:53:21,807 --> 00:53:22,377
Would recommend it.

1014
00:53:22,387 --> 00:53:25,797
It's a very, very long read, probably
one of the largest blog articles I've

1015
00:53:25,797 --> 00:53:28,387
seen in a very long while, but it's
definitely worthwhile if you want

1016
00:53:28,387 --> 00:53:30,107
to get a more holistic viewpoint.

1017
00:53:30,327 --> 00:53:31,717
And he's written a lot
of articles like this.

1018
00:53:31,737 --> 00:53:34,537
Another great one that he's written
just to give a shout out is called

1019
00:53:34,597 --> 00:53:38,437
modularizing React applications
with established UI patterns.

1020
00:53:38,587 --> 00:53:41,652
And this is one that Mark is not going
to be very happy about, but this one

1021
00:53:41,652 --> 00:53:45,080
is one of those, which is like, how
do you enterprise ify React code,

1022
00:53:45,194 --> 00:53:47,874
but it's actually a very interesting
article that has some thoughts about

1023
00:53:47,874 --> 00:53:49,384
how you should architect React apps.

1024
00:53:49,504 --> 00:53:52,964
And some of those patterns, not all
of them, are actually very good to

1025
00:53:52,964 --> 00:53:55,704
make it easier for you to do things
like testing and so on and so forth.

1026
00:53:55,914 --> 00:53:56,244
Carl Vitullo: Cheers.

1027
00:53:56,244 --> 00:53:56,534
Yeah.

1028
00:53:56,710 --> 00:54:01,787
Oh man, I remember reading Martin
Fowler's blog like 15 years ago

1029
00:54:01,787 --> 00:54:03,527
when I was like starting my career.

1030
00:54:03,527 --> 00:54:07,267
So just for it to still be relevant is
like a little bit mind boggling to me.

1031
00:54:07,430 --> 00:54:10,220
Mo Khazali: The website still looks
like it's from 15 years ago as well.

1032
00:54:10,280 --> 00:54:10,590
Carl Vitullo: Yeah.

1033
00:54:10,590 --> 00:54:13,380
It's unchanged from when
I started reading it.

1034
00:54:13,380 --> 00:54:13,680
Yeah.

1035
00:54:13,954 --> 00:54:15,764
Not a single change that I can identify.

1036
00:54:16,304 --> 00:54:16,564
Cool.

1037
00:54:16,564 --> 00:54:16,804
Yeah.

1038
00:54:16,804 --> 00:54:21,794
I wanted to bring up a
blog from Snyk, a security.

1039
00:54:21,829 --> 00:54:25,462
Firm, I don't know, security
product service, 10 modern Node.

1040
00:54:25,462 --> 00:54:28,672
js runtime features to
start using in 2024.

1041
00:54:28,895 --> 00:54:32,625
It's, I have always found it really
tricky to stay on top of every

1042
00:54:32,625 --> 00:54:35,259
level of development over time.

1043
00:54:35,259 --> 00:54:38,239
So I appreciate a little roundup post
like this that just sort of calls

1044
00:54:38,239 --> 00:54:42,909
out a number of new features that I
may not have caught the release of.

1045
00:54:42,945 --> 00:54:46,575
It's sometimes it's hard to see,
see the each individual release.

1046
00:54:46,965 --> 00:54:50,165
So the 10 that they call
out are a test runner.

1047
00:54:50,335 --> 00:54:54,525
Native mocking, native test
coverage, watch mode, core pack,

1048
00:54:54,769 --> 00:55:02,395
the env loader, some import meta
fields for the __dirname and __file

1049
00:55:02,495 --> 00:55:08,209
fields, native timers and promises,
permissions module and a policy module.

1050
00:55:08,239 --> 00:55:11,419
Those last two are not super clear
to me, but like the test runner and

1051
00:55:11,419 --> 00:55:13,559
native mocking and test coverage.

1052
00:55:13,724 --> 00:55:17,264
Super great to not have to pull
in a third party tool for that.

1053
00:55:17,450 --> 00:55:19,390
As well as, yeah, I mean, watch mode.

1054
00:55:19,517 --> 00:55:22,057
The number of times
I've installed NodeMon.

1055
00:55:22,164 --> 00:55:26,100
If I can stop relying on a third party
package for that, I'll be pretty happy.

1056
00:55:26,100 --> 00:55:27,080
I haven't checked that out yet, though.

1057
00:55:27,380 --> 00:55:32,007
CorePack is actually, I feel like
the name of it makes you compare

1058
00:55:32,007 --> 00:55:35,040
it to Webpack, or it makes me
compare it to Webpack, at least.

1059
00:55:35,040 --> 00:55:41,269
But actually, it's, the main use for it
is being able to specify a package manager

1060
00:55:41,619 --> 00:55:44,789
at a specific version, which is so useful.

1061
00:55:44,809 --> 00:55:47,649
Um, I appreciate that they have made
it, I guess it's a, I guess it's a

1062
00:55:47,649 --> 00:55:52,642
combination of being able to pin a
specific version of your package manager,

1063
00:55:52,749 --> 00:55:56,979
but it's also, I think, some underlying
tools to make cross compatibility

1064
00:55:57,075 --> 00:55:59,365
possible between package managers.

1065
00:55:59,624 --> 00:56:01,674
Mark Erikson: The primary
issue is that NPM has always

1066
00:56:01,674 --> 00:56:03,314
come pre installed with Node.

1067
00:56:03,410 --> 00:56:10,527
But if you want to use Yarn or PNPM,
or, Bun, I guess, you have to first use

1068
00:56:10,567 --> 00:56:13,577
NPM to install those tools globally.

1069
00:56:13,885 --> 00:56:16,865
And that's kind of a one
off per system thing.

1070
00:56:17,095 --> 00:56:20,155
And then you have to remind everybody
that they're supposed to be using

1071
00:56:20,165 --> 00:56:22,355
this package manager, the project.

1072
00:56:22,509 --> 00:56:27,282
And so I think the idea of CorePack is
that if you specify in your package JSON,

1073
00:56:27,292 --> 00:56:30,879
that, Hey, we're actually using Yarn 4.

1074
00:56:30,879 --> 00:56:33,096
1 or PMPM 9.

1075
00:56:33,096 --> 00:56:33,523
2.

1076
00:56:33,630 --> 00:56:37,660
It will automatically do the work to make
sure that the right package manager is

1077
00:56:37,660 --> 00:56:40,490
available and being used in that project.

1078
00:56:40,780 --> 00:56:41,060
Carl Vitullo: Right.

1079
00:56:41,080 --> 00:56:43,950
It fills the gap where,
like, PackageLock or Yarn.

1080
00:56:44,070 --> 00:56:50,550
Lock will let you pin your dependencies,
left the, you know, the gap of what

1081
00:56:50,550 --> 00:56:54,127
about the version, you know, for the
package manager because the different

1082
00:56:54,127 --> 00:56:57,497
versions interpret that lock file
slightly differently sometimes.

1083
00:56:57,517 --> 00:57:01,367
Or, you know, I've had a more recent
version of Yarn blow away my Yarn or,

1084
00:57:01,367 --> 00:57:06,237
you know, start adding things like a,
a digest half to the, to the lock file.

1085
00:57:06,247 --> 00:57:08,594
So being able to pin a
version, super great.

1086
00:57:08,644 --> 00:57:08,964
Yeah.

1087
00:57:09,014 --> 00:57:13,084
As well as like having a env loader,
so we don't need to use env anymore.

1088
00:57:13,314 --> 00:57:16,614
But yeah, so I appreciated this
as a quick summary of a number

1089
00:57:16,614 --> 00:57:18,470
of new built ins for Node.

1090
00:57:19,067 --> 00:57:22,207
Mark Erikson: There was a very
good post on migrating to the next

1091
00:57:22,247 --> 00:57:24,527
app router with zero downtime.

1092
00:57:24,754 --> 00:57:29,094
One of the pain points with server
components is that you have to have the

1093
00:57:29,104 --> 00:57:34,694
entire application set up with server
components as the outer layer of the

1094
00:57:34,694 --> 00:57:36,770
application in order to use them at all.

1095
00:57:36,780 --> 00:57:39,200
There's no straightforward,
simple, like migrate, just a

1096
00:57:39,200 --> 00:57:41,010
little piece of my component tree.

1097
00:57:41,255 --> 00:57:45,389
And while you can use the app router
with everything still on the client,

1098
00:57:45,429 --> 00:57:49,685
as a client component, it's still a key
step in order to even be able to think

1099
00:57:49,705 --> 00:57:51,645
about using server components with Next.

1100
00:57:51,819 --> 00:57:55,839
And so, this article was a good example
of how a team with an existing Next app

1101
00:57:55,849 --> 00:58:00,585
that used the Pages router was able to
mimic the routing setup in the app router

1102
00:58:00,585 --> 00:58:05,415
and carefully, step by step, make sure
that things worked the same both ways.

1103
00:58:05,504 --> 00:58:09,844
Switch over and then be able to
start using some server components

1104
00:58:09,864 --> 00:58:11,827
piece within the existing structure.

1105
00:58:12,530 --> 00:58:16,680
Carl Vitullo: All right, Deno announces
that the standard library is nearing 1.

1106
00:58:16,680 --> 00:58:16,910
0.

1107
00:58:17,190 --> 00:58:18,980
That sounds great to me.

1108
00:58:19,030 --> 00:58:23,230
The standard library is now a
collection of 38 packages, they say.

1109
00:58:23,290 --> 00:58:24,150
I appreciated this.

1110
00:58:24,550 --> 00:58:26,080
Rather than doing it
all in one big bang 1.

1111
00:58:26,080 --> 00:58:31,630
0 release for the standard library,
they're actually going to repeat a

1112
00:58:31,630 --> 00:58:36,760
process for bringing each of those
38 packages up to stable relief.

1113
00:58:36,770 --> 00:58:40,710
So they're gonna do it through like a
release candidate and then gather feedback

1114
00:58:40,750 --> 00:58:45,500
with like a a one month timeline for each
of those packages to gather feedback.

1115
00:58:45,940 --> 00:58:50,555
So yeah, that's A lot of effort, a lot
of energy being invested into creating

1116
00:58:50,555 --> 00:58:55,480
a standard library and oh man, here's
a standard library for a JS runtime.

1117
00:58:55,764 --> 00:58:56,464
Mark Erikson: I'm confused.

1118
00:58:56,464 --> 00:58:57,634
Are we allowed to have that?

1119
00:58:57,810 --> 00:58:58,220
Carl Vitullo: Right?

1120
00:58:58,300 --> 00:59:00,930
It's, it, the classic
criticism of JavaScript is the

1121
00:59:00,930 --> 00:59:02,150
lack of a standard runtime.

1122
00:59:02,160 --> 00:59:06,000
So, oh my goodness, we have a
standard runtime hitting stable.

1123
00:59:06,250 --> 00:59:08,800
I feel like that's going to affect
the ecosystem in some way, but we'll

1124
00:59:08,800 --> 00:59:09,930
have to see what happens there.

1125
00:59:10,604 --> 00:59:11,024
Cool.

1126
00:59:11,114 --> 00:59:11,974
I'm going to call this one out.

1127
00:59:11,984 --> 00:59:14,344
This was, I put, I put
up one of my tweets.

1128
00:59:14,344 --> 00:59:14,594
I don't know.

1129
00:59:14,594 --> 00:59:15,554
I think it's a good question.

1130
00:59:15,554 --> 00:59:16,234
I'm going to do it.

1131
00:59:16,560 --> 00:59:22,210
I proposed the question out, why did we
stop making checks like the ACID3 test?

1132
00:59:22,320 --> 00:59:26,345
Why isn't there an ACID3 test for,
for example, progressive web apps?

1133
00:59:26,544 --> 00:59:30,373
I remember the ACID test
series of, projects was

1134
00:59:30,383 --> 00:59:32,043
Mark Erikson: Browser rendering behaviors.

1135
00:59:32,053 --> 00:59:33,133
Carl Vitullo: Browser rendering behaviors.

1136
00:59:33,143 --> 00:59:37,743
It was, is the browser you're viewing
the web page in standards compliant?

1137
00:59:38,057 --> 00:59:39,567
Here is something.

1138
00:59:39,838 --> 00:59:41,108
It should look like this.

1139
00:59:41,398 --> 00:59:44,768
And I remember checking that
in, you know, 2008 or whatever,

1140
00:59:44,768 --> 00:59:46,218
when I was a wee baby nerd.

1141
00:59:46,669 --> 00:59:49,251
And, my browser didn't render
it correctly, and then a

1142
00:59:49,251 --> 00:59:50,271
couple years later it did.

1143
00:59:50,576 --> 00:59:55,440
I was considering, like, what factors
may have moved us away from things like

1144
00:59:55,440 --> 00:59:59,790
that, and I feel like it used to be so
hard to ship new things, new standards.

1145
01:00:00,020 --> 01:00:05,296
That it took big coordinated pushes
like that, or maybe the ecosystem was

1146
01:00:05,296 --> 01:00:09,686
also just smaller and the number of
players involved were, you know, it could

1147
01:00:09,686 --> 01:00:12,838
fit in a room, but I feel like we've
lost something a little bit in there.

1148
01:00:12,848 --> 01:00:17,794
Like the acid three test was CSS
three was ratified as a standard.

1149
01:00:17,997 --> 01:00:21,921
They put out an associated test for
this rendering behavior so that.

1150
01:00:22,088 --> 01:00:26,308
Users could check if their browser was
working in compliance with the standards.

1151
01:00:26,547 --> 01:00:31,340
And I guess I, I put up the comparison to
progressive web apps because like, They

1152
01:00:31,340 --> 01:00:36,814
are not fully rolled out, like Chrome
put out, the Chrome team put out a lot

1153
01:00:36,834 --> 01:00:42,382
of support for progressive web apps, very
much as a attempt, I think, to make web

1154
01:00:42,382 --> 01:00:47,056
pages viable as competitors to native
apps, and it just kind of never really

1155
01:00:47,056 --> 01:00:51,913
happened, I think in large part because
we never got cross compatibility With

1156
01:00:51,913 --> 01:00:54,233
all the browsers for those capabilities.

1157
01:00:54,379 --> 01:00:59,649
And I don't even know that we, as an
ecosystem, as web developers, have

1158
01:00:59,649 --> 01:01:04,189
a shared understanding of what makes
a progressive web app, you know,

1159
01:01:04,189 --> 01:01:05,709
what defines a progressive web app?

1160
01:01:05,856 --> 01:01:10,023
How do you distinguish that what
you've made meets all the criteria?

1161
01:01:10,033 --> 01:01:10,503
So, I don't know.

1162
01:01:10,513 --> 01:01:16,269
I just, it was lamenting our lack of
those sort of litmus tests for, I guess,

1163
01:01:16,369 --> 01:01:21,231
bringing a Technical definition to some of
the terms that we throw around frequently.

1164
01:01:21,421 --> 01:01:25,351
Mark Erikson: It's, it's not quite what
you're asking for here, but I can point

1165
01:01:25,361 --> 01:01:30,124
to a couple ways that there's been more
efforts to do interoperability efforts.

1166
01:01:30,188 --> 01:01:35,088
One is I think the latest version
of the speedometer benchmark for JS

1167
01:01:35,088 --> 01:01:38,288
engines was specifically built to
include a bunch of different things.

1168
01:01:38,354 --> 01:01:43,194
Reasonable, plausible example applications
using various JavaScript frameworks.

1169
01:01:43,324 --> 01:01:46,604
Like I know that there's like a
React, Redux, Todo application as

1170
01:01:46,614 --> 01:01:48,314
part of the benchmark sequence.

1171
01:01:48,404 --> 01:01:52,181
So that's been an attempt to
semi standardize things and make

1172
01:01:52,181 --> 01:01:53,271
things a little more plausible.

1173
01:01:53,581 --> 01:01:58,019
Also, I believe the last three or four
years, all the major browser Vendors have

1174
01:01:58,029 --> 01:02:02,373
done, I don't remember the exact term but
like an interoperability effort where they

1175
01:02:02,373 --> 01:02:08,066
identify like the top five or six pain
points of places we know where browser

1176
01:02:08,066 --> 01:02:12,329
behavior is differing and we're all going
to make a push this year to make sure we

1177
01:02:12,339 --> 01:02:15,299
all work the same way for these things.

1178
01:02:15,496 --> 01:02:20,209
So it's, it's not quite the same as
having like the ACID3 test or, you

1179
01:02:20,209 --> 01:02:25,103
know, a named version of CSS that
we're all trying to implement, but it

1180
01:02:25,103 --> 01:02:26,913
is, it is kind of along those lines.

1181
01:02:27,139 --> 01:02:27,449
Carl Vitullo: Right.

1182
01:02:27,529 --> 01:02:27,839
Yeah.

1183
01:02:27,889 --> 01:02:28,199
I don't know.

1184
01:02:28,199 --> 01:02:33,009
I guess I, I, I think the branding
that used to be baked in to

1185
01:02:33,009 --> 01:02:37,043
those sort of releases served, I
think to me, it served a valuable

1186
01:02:37,229 --> 01:02:39,369
function in developer education.

1187
01:02:39,379 --> 01:02:41,369
And I think that we've lost
something through not having it.

1188
01:02:41,379 --> 01:02:47,386
Like there was a web platform tests
dashboard that like, yes, here is a single

1189
01:02:47,386 --> 01:02:52,273
place that compares all of the features,
accessibility, all of the compatibility

1190
01:02:52,273 --> 01:02:56,156
across browsers, but it's not actually,
you know, as a developer, it doesn't tell

1191
01:02:56,156 --> 01:02:58,668
me what features are grouped together?

1192
01:02:58,678 --> 01:03:00,838
What features go well together?

1193
01:03:01,248 --> 01:03:05,238
What capabilities are unlocked
by supporting this thing?

1194
01:03:05,378 --> 01:03:08,428
We're going well beyond the scope
of a lightning round link right now.

1195
01:03:09,141 --> 01:03:11,151
Mark Erikson: all right, and
last one we got on the list.

1196
01:03:11,181 --> 01:03:17,301
HTMX is a library for basically adding
attributes to HTML tags that do things

1197
01:03:17,301 --> 01:03:21,231
like data fetching and automatically
inserting the results into the page

1198
01:03:21,348 --> 01:03:25,329
without having to explicitly write
JavaScript yourself, and they put

1199
01:03:25,329 --> 01:03:29,819
up a blog post entitled Simplicity
in an Age of Complicated Solutions,

1200
01:03:29,913 --> 01:03:33,933
where they have some examples of
handling inputs and data fetching

1201
01:03:33,953 --> 01:03:36,823
with VanillaJS or with React code.

1202
01:03:37,056 --> 01:03:39,476
And they point out and say,
look at how complicated this is.

1203
01:03:39,719 --> 01:03:43,459
Whereas if we just slap HTML
into the page and we add a couple

1204
01:03:43,459 --> 01:03:45,553
attributes, look at how simple this is.

1205
01:03:45,814 --> 01:03:48,324
And there's, there's some valid
trains of thought to this.

1206
01:03:48,334 --> 01:03:50,964
Certainly you're writing less
code as an application developer.

1207
01:03:51,154 --> 01:03:54,714
I questioned a little bit some of
their arguments on general principle,

1208
01:03:54,774 --> 01:03:59,321
but it is worth reading for an
alternate viewpoint on how application

1209
01:03:59,321 --> 01:04:00,581
behavior should be implemented.

1210
01:04:00,811 --> 01:04:03,441
Carl Vitullo: Yeah, definitely
interesting from a perspective of just

1211
01:04:03,541 --> 01:04:05,721
considering expansion of complexity too.

1212
01:04:05,751 --> 01:04:08,364
I thought that was, I thought it
was cool to read from that lens too.

1213
01:04:08,884 --> 01:04:09,204
Cool.

1214
01:04:09,534 --> 01:04:09,994
All right.

1215
01:04:09,994 --> 01:04:12,434
That is all of the, all the links we have.

1216
01:04:12,624 --> 01:04:13,654
Thanks everyone for joining us.

1217
01:04:13,674 --> 01:04:16,564
We'll be back on the last Wednesday
of the month in here in the live

1218
01:04:16,564 --> 01:04:20,624
stage of Reactiflux or in your podcast
feed as soon as we can after that.

1219
01:04:20,914 --> 01:04:21,894
Mark Erikson: Thank you for listening.

1220
01:04:21,928 --> 01:04:23,768
Plug, please check out Replay.

1221
01:04:23,768 --> 01:04:28,064
io for debugging your tests
and trying to fix flakes.

1222
01:04:28,124 --> 01:04:33,514
And also, I'm almost done with a
very large revamp of the primary

1223
01:04:33,514 --> 01:04:37,598
Redux tutorial to make it TypeScript
first and explain more things.

1224
01:04:37,703 --> 01:04:41,506
Carl just pasted a link
to the draft PR in there.

1225
01:04:41,806 --> 01:04:43,176
I would appreciate feedback.

1226
01:04:43,256 --> 01:04:46,746
I'm hoping to have this done
within the next couple weeks.

1227
01:04:46,746 --> 01:04:49,706
Like, I'm almost done with the first
draft, and then hopefully there's

1228
01:04:49,716 --> 01:04:50,906
not too much more work to do.

1229
01:04:51,196 --> 01:04:52,556
So, feedback, please?

1230
01:04:52,756 --> 01:04:53,296
Carl Vitullo: For sure.

1231
01:04:53,786 --> 01:04:54,236
Awesome.

1232
01:04:54,273 --> 01:04:54,483
Yeah.

1233
01:04:54,483 --> 01:04:55,373
Mo, anything you want to add?

1234
01:04:55,586 --> 01:04:56,026
Mo Khazali: Nothing.

1235
01:04:56,026 --> 01:04:59,266
Just thank you again for having me
and always a lovely time chatting

1236
01:04:59,306 --> 01:05:01,946
with you all and going over
everything that's been happening.

1237
01:05:02,126 --> 01:05:03,586
And yeah, looking forward to the next one.

1238
01:05:03,849 --> 01:05:04,619
Carl Vitullo: Most definitely.

1239
01:05:04,639 --> 01:05:05,019
Yeah.

1240
01:05:05,126 --> 01:05:06,416
Always good talking to you guys.

1241
01:05:06,506 --> 01:05:06,916
Cool.

1242
01:05:07,199 --> 01:05:10,399
we, we gather links from, um,
a bunch of different sources,

1243
01:05:10,399 --> 01:05:12,849
including thisweekinreact, bytes.

1244
01:05:12,859 --> 01:05:17,459
dev, reactstatus, nextjsweekly,
the reactjs subreddit.

1245
01:05:17,459 --> 01:05:17,589
Bye.

1246
01:05:17,769 --> 01:05:22,689
Here in Reactiflux from the Tech Reads
and News channel, um, and directly

1247
01:05:22,699 --> 01:05:26,189
from people publishing articles,
usually on like Twitter or Blue Sky.

1248
01:05:26,689 --> 01:05:29,329
If you see anything that you
think that we should be paying

1249
01:05:29,329 --> 01:05:33,499
attention to, definitely feel free
to email us at hello at reactiflux.

1250
01:05:33,539 --> 01:05:36,089
com with T M I R in the subject line.

1251
01:05:36,149 --> 01:05:37,289
That's acronym for the show.

1252
01:05:37,643 --> 01:05:40,233
I read every email that comes
in, even the ones marked as spam.

1253
01:05:40,559 --> 01:05:43,089
If this is the show you get value
from and want to support, the best

1254
01:05:43,089 --> 01:05:45,823
way to do so is to send it to someone.

1255
01:05:45,949 --> 01:05:49,559
Send it to your co workers, help them
learn how you know so much about React.

1256
01:05:50,046 --> 01:05:52,596
Otherwise, you know, submit
a review, do stuff like that.

1257
01:05:52,993 --> 01:05:54,909
But yeah, thank you so
much for joining us.

1258
01:05:55,129 --> 01:05:55,629
Appreciate it.

1259
01:05:56,033 --> 01:05:56,533
See you next month.