WEBVTT

1
00:00:05.200 --> 00:00:10.080
Hey, everybody, welcome back to
another episode of JavaScript Jabber. This week

2
00:00:10.119 --> 00:00:13.000
on our panel, we have a
j O'Neill Yo yo yo, coming at

3
00:00:13.000 --> 00:00:18.480
you live from an eight hundred c
C engine. Not really though, but

4
00:00:18.600 --> 00:00:24.440
I am looking at getting a motorcycle, all right, Dan Shapiir Hi from

5
00:00:24.440 --> 00:00:29.679
a warm and somewhat MUGGI tel Aviv
Uh huh. I'm Charles max Wood from

6
00:00:29.719 --> 00:00:33.799
Top End Devs. And yeah,
this week we have two guests. We

7
00:00:33.840 --> 00:00:37.399
have Satya. I don't see your
last name, so my friend, you're

8
00:00:37.439 --> 00:00:41.280
gonna have to tell us who you
are. Hi, I'm Satia Gone.

9
00:00:43.159 --> 00:00:50.359
I was just gonna say that you
now. Honestly, Uh, Microsoft getting

10
00:00:50.359 --> 00:00:53.600
Tatia is their CEO. It's the
best thing that have that has happened to

11
00:00:53.640 --> 00:01:03.479
me, right because I don't confounce
my name at least in that our good

12
00:01:03.479 --> 00:01:06.599
deal. We also have Joe Savona. Hey, nice to be great to

13
00:01:06.640 --> 00:01:07.799
be here, Thanks for having us. So yeah, Joe, I went

14
00:01:07.799 --> 00:01:12.120
and looked. I'm pretty sure we
haven't had Satian before, but uh,

15
00:01:12.519 --> 00:01:18.159
you were on in twenty fifteen we
were talking about Relay and Graphuel, So

16
00:01:19.040 --> 00:01:22.239
welcome back. It's been a while. Yeah, and last year for RC

17
00:01:22.519 --> 00:01:27.640
yeah, yeah, you might need
that one. Yeah. Yeah. We

18
00:01:29.000 --> 00:01:33.840
spoke with with Dan Abramov and Joe
together about you're right, it just doesn't

19
00:01:33.840 --> 00:01:41.200
have your name in the title because
it sucks the room exactly. It doesn't

20
00:01:41.239 --> 00:01:46.959
have dance name in the title either, but that's we'll blame it on Dan

21
00:01:47.040 --> 00:01:53.079
though. Yeah, he's not here. Yeah, all right, So we're

22
00:01:53.120 --> 00:01:57.040
here to talk about the Reaction compiler, and there was a big announcement I

23
00:01:57.040 --> 00:02:00.439
guess within the last week or so. I'm sorry, I'm in and this

24
00:02:00.560 --> 00:02:04.239
time crunch where like time dilates,
and so I don't know if it was

25
00:02:04.239 --> 00:02:06.560
two weeks ago or two months ago, but I know it was recent.

26
00:02:07.280 --> 00:02:10.400
So do you want to fill us
in on what we're talking about today?

27
00:02:10.439 --> 00:02:15.400
Just kind of set the stage and
then we can dive into what it means.

28
00:02:15.800 --> 00:02:19.680
Yeah, Sothia, do you want
to As you take a sip of

29
00:02:19.680 --> 00:02:23.919
water, I'll punt it to you. Sure. Yeah, we had React

30
00:02:23.960 --> 00:02:30.680
cong a couple of weeks ago we
announced the open sourcing of the React compiler,

31
00:02:30.439 --> 00:02:36.280
which we've been working on for almost
doing of yours three years at this

32
00:02:36.360 --> 00:02:40.840
point, so it's been a it's
been a while, and yeah, it's

33
00:02:42.159 --> 00:02:46.919
open source, you can fry it. Today there's a bubble plug in that

34
00:02:46.960 --> 00:02:53.080
you can pull on your apps.
You'll React app and it gets automatically memoized.

35
00:02:54.120 --> 00:02:58.919
You no longer have to think about
use memo and used callback and React

36
00:02:58.919 --> 00:03:07.199
out memo. Oh, the compiler
hups remove the malmanimalization. And then there's

37
00:03:07.199 --> 00:03:13.039
also an e slump plug in that
helps you catch bugs. So when you

38
00:03:13.120 --> 00:03:15.919
violate the rules of React, the
plug in will help you, so you

39
00:03:15.960 --> 00:03:23.199
can write bug free React code.
Okay, I'm confused in what sense do

40
00:03:23.240 --> 00:03:27.639
we mean? No, I really
am. So, first of all,

41
00:03:27.680 --> 00:03:30.960
I'm not I'm not a front in
person. I do mostly server side.

42
00:03:30.520 --> 00:03:34.840
Okay, So when I think of
a compiler, I think of like either

43
00:03:35.280 --> 00:03:38.439
compiler or transpiler. Transpiler the way
that React currently works, where you do

44
00:03:38.560 --> 00:03:46.479
an amalgamation of HTML and JavaScript and
it compiles or transpiles to JavaScript, or

45
00:03:46.560 --> 00:03:51.159
a compiler to something that produces bytecode
or machine code. So when you say

46
00:03:51.240 --> 00:03:54.960
compiler it it's at first it sounds
like what you're just saying, like what

47
00:03:55.000 --> 00:04:01.240
I already know about React. There's
a thing that transpiles some code from one

48
00:04:01.240 --> 00:04:04.639
thing to another. But then you're
introducing it, which means that it's not

49
00:04:04.800 --> 00:04:10.280
what I think it is. Yeah, before you guys answer, before you

50
00:04:10.319 --> 00:04:14.199
guys answer, I actually have to
interject and say that I got into a

51
00:04:14.240 --> 00:04:17.680
little bit of trouble, I think
with some members of your team when I

52
00:04:17.720 --> 00:04:24.360
stated on X yeah that I don't
actually consider it to be a compiler because

53
00:04:24.439 --> 00:04:30.040
one, technically, I understand why
you're why you're calling a compiler, because

54
00:04:30.279 --> 00:04:33.519
it works like a compiler, and
there's you know, a SDS and whatnot.

55
00:04:34.519 --> 00:04:44.000
It's taking JavaScript and translate valid JavaScript
and translating it into valid JavaScript,

56
00:04:44.839 --> 00:04:49.600
so uh, you know, usually
no, it's not about thees X.

57
00:04:49.680 --> 00:04:56.040
It's about taking support and yeah obviously
yeah obviously, and also typescript, I

58
00:04:56.040 --> 00:05:00.439
guess. But but you know,
at the most big sick level, it's

59
00:05:00.439 --> 00:05:08.800
taking perfectly valid JavaScript and translating it
into perfectly valid JavaScript, which doesn't sound

60
00:05:09.040 --> 00:05:14.480
like what compilers are supposed to be
doing. They're supposed to be taking stuff

61
00:05:14.480 --> 00:05:20.000
in language X and trans and transforming
it into language Y. So but then,

62
00:05:20.199 --> 00:05:24.000
you know, people told me that
I was nitpicking, which is,

63
00:05:24.240 --> 00:05:28.879
you know, probably true because I'm
a nitpicker. But be that as it

64
00:05:28.920 --> 00:05:35.000
may. Now, I let you
kind of answer a J's question, right,

65
00:05:35.560 --> 00:05:43.079
So generally, like in the fund
end ecosystem, there's there's been babble

66
00:05:43.279 --> 00:05:46.000
which we used to do transformations on
the estage, right, That's that's where

67
00:05:46.399 --> 00:05:54.160
that's honestly how or like why the
dumb transplanter became popular listen to jazz community

68
00:05:55.279 --> 00:06:00.879
is the transformations using bubble. But
I think I think in that aspect,

69
00:06:00.959 --> 00:06:04.800
yes, the REAC compiler is a
transpiler that is a source source transformation,

70
00:06:05.199 --> 00:06:12.800
but the kind of analysis and the
how the compiler, like the compiler actually

71
00:06:12.879 --> 00:06:17.040
works is a more like a traditional
compiler, like how we it would work,

72
00:06:18.160 --> 00:06:24.399
which is why we call it the
REAC compiler. We do lower it

73
00:06:24.800 --> 00:06:29.759
to not just a st but the
like very low level I R, and

74
00:06:29.839 --> 00:06:33.480
then we compile that back to source
just because we're want to ship that as

75
00:06:33.560 --> 00:06:40.600
Chaska. So for the benefit of
our listeners and myself. What what's I

76
00:06:40.839 --> 00:06:46.079
R and then what's a STU?
Right, So generally, in a in

77
00:06:46.079 --> 00:06:50.439
a compiler pipeline, the source code
is the first step of the compiler pipeline

78
00:06:50.480 --> 00:06:57.519
is converting the source text, which
is j syntax into abstracts and tax three

79
00:06:57.560 --> 00:07:02.920
which is like three of nodes representing
which has some semantic information about your input,

80
00:07:03.000 --> 00:07:08.480
and you can do a lot of
analysis transformations on this and it is

81
00:07:08.680 --> 00:07:13.560
pretty powerful. But there are some
limitations to this data structure because it's a

82
00:07:13.600 --> 00:07:20.839
tree. And then generally compilers lower
this to another data structure called intermediate reputation,

83
00:07:21.519 --> 00:07:27.560
which is most generally a control flow
graph, so it's more like a

84
00:07:27.600 --> 00:07:33.000
graph rather than a tree of notes, so you can do more advanced optimizations

85
00:07:33.040 --> 00:07:39.800
and analysis on this data structure.
So what what's the nuance between tree and

86
00:07:39.879 --> 00:07:46.120
graph? Because when I hear the
two, normally they're synonymous. Mm hmm.

87
00:07:47.160 --> 00:07:49.879
One is snick click, one is
cyclic, and the other isn't.

88
00:07:50.360 --> 00:07:55.079
Well, okay, yeah, tree, tree is directed. It kind of

89
00:07:55.120 --> 00:07:58.800
goes one way. Ye, tree
is a kind of a graph, like

90
00:07:58.839 --> 00:08:01.319
every tree is a graph, but
not that a graph is a tree,

91
00:08:01.399 --> 00:08:07.759
right, got it right? So
that REAC compiler does lower to this sort

92
00:08:07.759 --> 00:08:13.560
of lower level i R, which
is like a graph, which is which

93
00:08:13.560 --> 00:08:18.560
is why we call it a compiler. So you can just add on Yeah,

94
00:08:18.639 --> 00:08:20.920
go ahead, yeah, I would
just add so I think you know,

95
00:08:22.040 --> 00:08:24.040
well, first off, transpilers are
a subset of compilers, right,

96
00:08:24.480 --> 00:08:28.399
and in the ecosystem. If you
look at if you go to babbelsme page,

97
00:08:28.720 --> 00:08:31.440
they say you gotta you gotta,
you gotta type script. They call

98
00:08:31.480 --> 00:08:33.799
it a compiler, right, so
so part so part of it. So

99
00:08:33.799 --> 00:08:37.039
it's kind of two aspects. One
the way it works is a compiler.

100
00:08:37.840 --> 00:08:43.279
The other aspect is naming it in
a way that developers actually understand what what

101
00:08:43.320 --> 00:08:46.720
it is, which is, when
you look around, similar types of things

102
00:08:46.720 --> 00:08:50.879
are being are you know, in
the JS ecosystem known as compilers, and

103
00:08:50.960 --> 00:08:56.639
this is doing you know, some
something similar, actually more sophisticated in a

104
00:08:56.639 --> 00:08:58.399
lot of cases than what we've seen
before. So I think, like really

105
00:08:58.440 --> 00:09:01.759
to understand why we're calling it a
compiler, it helps get into what it's

106
00:09:01.840 --> 00:09:05.559
doing. Right, It's not just
about the fact that we're lowing lower into

107
00:09:05.559 --> 00:09:07.480
an IR and a control flowgraph,
but it's really about like what is the

108
00:09:07.480 --> 00:09:11.840
compiler doing what, Like, how
does understand your code? What transformations is

109
00:09:11.840 --> 00:09:16.080
it applying the right to help you
have you know, right, nice clean

110
00:09:16.600 --> 00:09:18.399
job, you know, react code
like you're used to and get better performance

111
00:09:18.440 --> 00:09:22.080
at the you know, on the
output. I think once one's kind of

112
00:09:22.120 --> 00:09:24.080
understand what it's doing in the full
pipeline, then it becomes clear why we're

113
00:09:24.120 --> 00:09:28.240
calling it a compiler. Yeah,
I just I want to jump in here

114
00:09:28.279 --> 00:09:33.240
real quick because it feels like,
you know, you brought me this the

115
00:09:33.440 --> 00:09:37.639
sweet sweet ride, and you're telling
me what makes the pistons go up and

116
00:09:37.679 --> 00:09:41.159
down? And what I care about
is how it's going to get me down

117
00:09:41.159 --> 00:09:45.399
the street so that I can go
to the groceries. Exactly what matters is

118
00:09:45.440 --> 00:09:48.879
not yeah, exactly. So so
I'm going to ask why do I care?

119
00:09:50.960 --> 00:09:52.080
Right? What does this do for
me? That's a great question,

120
00:09:52.200 --> 00:10:01.320
yes, Sathya. Well do you
mean like the why we why we have

121
00:10:01.440 --> 00:10:05.759
the compiler? Or yeah? Basically, so, you know, I'm writing

122
00:10:05.799 --> 00:10:09.279
this awesome React app, you know, maybe I'm using next JS, or

123
00:10:09.320 --> 00:10:11.840
maybe I'm just you know, hey, look, I do rails, right,

124
00:10:11.879 --> 00:10:15.679
So maybe I have an API and
I'm just doing React off of the

125
00:10:15.720 --> 00:10:20.440
API. But at the end of
the day, how is it going to

126
00:10:20.600 --> 00:10:22.879
make my app better? How is
it going to make my life easier,

127
00:10:22.879 --> 00:10:26.799
How is it going to make my
user's life easier? Or does it not

128
00:10:26.840 --> 00:10:28.960
do any of those things? But
I care about it for a completely unrelated

129
00:10:30.000 --> 00:10:37.240
reason. Right, So what we've
found out is reacting. Sometimes we do

130
00:10:37.360 --> 00:10:43.720
reactive and that it can revender it
more than necessary and to fix that and

131
00:10:43.080 --> 00:10:48.360
revending too much can be a performance
issue in certain cases. And to fix

132
00:10:48.399 --> 00:10:54.960
that, React gives you APIs like
use memo, just called back and React

133
00:10:54.960 --> 00:11:01.320
with memo. But using that is
a mental tax for developed because they have

134
00:11:01.320 --> 00:11:05.080
to think about something other than building
UIs right, like, you don't want

135
00:11:05.120 --> 00:11:09.039
to be thinking about memorization. You
want to be think about solving your user's

136
00:11:09.080 --> 00:11:13.039
problem. So the compiler comes in
automatically adds all of this to you to

137
00:11:13.120 --> 00:11:18.279
your app. I like to say, and I would like to interject here

138
00:11:18.279 --> 00:11:22.200
a little bit that First of all, I have to say that even the

139
00:11:22.279 --> 00:11:28.840
term rerender was confusing, at least
for me for a while, because you

140
00:11:28.840 --> 00:11:35.159
can think about two levels of rendering
or re rendering going on in the context

141
00:11:35.240 --> 00:11:39.399
of React. One level is the
generation of the virtual dome when you write,

142
00:11:39.559 --> 00:11:45.039
when your code, the React code
that you wrote as a React developer,

143
00:11:45.120 --> 00:11:50.399
runs and builds the virtual dop.
And then there is another rendering that

144
00:11:50.559 --> 00:11:58.679
happens when React itself takes the virtual
dome and transforms it into updates to the

145
00:11:58.720 --> 00:12:05.559
actual browser dot Now from my perspective
from almost day one, or essentially from

146
00:12:05.639 --> 00:12:11.879
day one, you kind of solve
the performance issue around the lower level rerendering.

147
00:12:11.919 --> 00:12:15.840
That's what the virtual dome was created
for, the whole reconciliation exactly.

148
00:12:16.399 --> 00:12:20.080
You know, there are some interesting
things going on with million js. I

149
00:12:20.120 --> 00:12:22.799
know, for example, they're trying
a different approach it might which might be

150
00:12:22.799 --> 00:12:26.879
beneficial in some cases. But at
the end of the day, it's solved

151
00:12:26.960 --> 00:12:33.480
and very efficiently in most cases by
React itself at that lower level. The

152
00:12:35.720 --> 00:12:39.320
place where we still had the problem, turns out, was at the higher

153
00:12:39.399 --> 00:12:46.200
level of creating the virtual dome.
Because initially, when React was pitched to

154
00:12:46.320 --> 00:12:50.519
us way back like almost a decade
ago, essentially a decade ago, we

155
00:12:50.519 --> 00:12:54.559
were kind of told that, hey, virtual dome is really cheap. It's

156
00:12:54.799 --> 00:13:01.720
just JavaScript objects. You know,
they're they're lightweight, there's little low effort

157
00:13:01.799 --> 00:13:05.879
related to it. The browser is
really good at managing JavaScript objects. Turns

158
00:13:05.879 --> 00:13:16.279
out that in some cases you guys
were lying, well, I'm gonna interject

159
00:13:16.320 --> 00:13:20.320
there just because yeah, yeah,
sorry, go for it. Yeah,

160
00:13:20.360 --> 00:13:26.559
I think I think what what what
has changed is that like the size and

161
00:13:26.600 --> 00:13:30.120
complexity of applications. Yeah, so
you're absolutely right, that like there's kind

162
00:13:30.159 --> 00:13:33.399
of these like two levels of rendering
happening. There's the like the JavaScript React

163
00:13:33.559 --> 00:13:39.039
rendering, you know, calling component
functions, right, and then the code

164
00:13:39.080 --> 00:13:41.879
that they that they call, and
then there's okay that creates a virtual domb,

165
00:13:41.879 --> 00:13:45.240
and then there's React then doing the
diffing of the virtual dumb. You're

166
00:13:45.279 --> 00:13:48.159
right, So React has really solved
that, you know, actually making the

167
00:13:48.200 --> 00:13:52.840
minimum number of DOMB modifications. Right. That that's like always been like React

168
00:13:52.840 --> 00:13:56.799
strength, But what's happened over time
is pure building larger and larger applications with

169
00:13:56.799 --> 00:14:01.440
this more and more product code,
right that that that high level rendering,

170
00:14:01.720 --> 00:14:05.960
and so that is where that the
time is really coming from. So you

171
00:14:05.960 --> 00:14:09.480
know, like I think the community
focuses a lot on like you know,

172
00:14:09.559 --> 00:14:13.080
kind of time spent in the framework, but what we see in practice is

173
00:14:13.080 --> 00:14:16.120
that most time is spent in user
code and in the product code. And

174
00:14:16.200 --> 00:14:20.320
so where the React compiler is really
helping is in making it so that we

175
00:14:20.399 --> 00:14:24.440
only run the minimal set of product
code that we need to when state changes,

176
00:14:24.799 --> 00:14:28.320
right, and then that complements the
lower level piece of only making the

177
00:14:28.360 --> 00:14:33.159
necessary DWN modifications. Yeah, and
again in this context. First of all,

178
00:14:33.159 --> 00:14:35.960
I have to say that I love
React, So you know, if

179
00:14:35.960 --> 00:14:41.120
it comes across as if I'm being
critical, it's it's criticism from love.

180
00:14:41.559 --> 00:14:48.279
We appreciate, We appreciate good criticism. Yeah. Actually, yes, I've

181
00:14:48.279 --> 00:14:56.039
been using React since twenty fourteen,
so I'm really a long time React user.

182
00:14:56.679 --> 00:15:01.720
I think some of the one of
the first actually outside of Meta itself,

183
00:15:01.679 --> 00:15:07.960
and so I'm really appreciative of that. And I was even teaching React

184
00:15:07.000 --> 00:15:11.519
for a while, and when I
was when I was teaching React, you

185
00:15:11.559 --> 00:15:15.639
know, one of the strengths of
React that that I was trying to convey

186
00:15:16.279 --> 00:15:24.159
was that whole pure approach of transforming
state into UI and that in an ideal

187
00:15:24.360 --> 00:15:31.360
world, if it was possible,
we would be re rendering everything from scratch

188
00:15:31.759 --> 00:15:37.320
on every change just to make everything
like you know, stateless as it were,

189
00:15:37.559 --> 00:15:43.639
like as pure as possible state in
UI out. But you know,

190
00:15:43.960 --> 00:15:50.159
reality uh gets in a way and
then and that's why we have all the

191
00:15:50.279 --> 00:15:58.000
sophistication behind the reconciliation and the virtual
dome to get to avoid the excessive dom

192
00:15:58.240 --> 00:16:06.240
updates. And from my perspective,
the React compiler is kind of like the

193
00:16:06.279 --> 00:16:11.279
final step that the filling in the
missing link in this process, because almost

194
00:16:11.320 --> 00:16:15.399
from the beginning we've had to deal
with all sorts of annoying things like should

195
00:16:15.399 --> 00:16:22.840
component update and then you know,
replaced by memo and use memo maybe I'm

196
00:16:22.879 --> 00:16:30.080
forgetting something in the middle, And
now ideally, hopefully we can finally forget

197
00:16:30.440 --> 00:16:37.440
about these things. Hint, hint, React forget. That's we couldn't have

198
00:16:37.440 --> 00:16:44.679
said it better. Yeah, so
can you now? So the benefit really,

199
00:16:44.960 --> 00:16:49.080
and that goes back to Chuck's question, I think, is the fact

200
00:16:49.279 --> 00:16:57.000
that your app becomes potentially significantly more
performant without you needing to change anything.

201
00:16:59.120 --> 00:17:03.840
Yeah, exactly right. It's that
it's that UI as a function of state.

202
00:17:04.559 --> 00:17:08.079
That that's something that we've really seen
that makes React so approachable to everyone

203
00:17:08.160 --> 00:17:11.799
is that you write your app as
if it is going to render. The

204
00:17:11.960 --> 00:17:15.440
entire thing is going to render every
single time, right, so that the

205
00:17:15.440 --> 00:17:19.599
whole like as they mentioned it being
like too reactive. It's like there's never

206
00:17:19.599 --> 00:17:23.079
a point if, for example,
if you kind of forget about use memo

207
00:17:23.079 --> 00:17:29.519
independencies, right, just JSX is
never going to forget to update, right

208
00:17:29.920 --> 00:17:33.079
if you just write regular React code
without any memoization, right, all the

209
00:17:33.119 --> 00:17:37.200
all the values will correctly propagate into
your app. So it's kind of fully

210
00:17:37.240 --> 00:17:40.960
reactive by default, and it's really
hard to kind of mess that up.

211
00:17:41.000 --> 00:17:42.799
The only places that you can mess
it up are when you start getting into

212
00:17:42.960 --> 00:17:45.359
Okay, let me write it use
memo. Oops, I forgot a dependency

213
00:17:45.720 --> 00:17:49.880
and so now something doesn't update,
right. So and so it's by having

214
00:17:49.920 --> 00:17:53.839
the compiler do the memoization for you, we can make it that you keep

215
00:17:53.880 --> 00:17:57.680
that same mental model of just writing
simple you know, simple functions, pure

216
00:17:57.680 --> 00:18:03.960
functions of mapping state to you why
uh, and you get that same mental

217
00:18:03.000 --> 00:18:06.839
model, but under the hood,
only the minimal parts of the COULDE are

218
00:18:06.839 --> 00:18:10.920
actually running that need to. So
can I clarify a couple of things?

219
00:18:11.839 --> 00:18:14.440
First of all, it's you know, I'm going to back way up and

220
00:18:14.440 --> 00:18:17.559
then kind of come forward. But
before I do that, the first thing

221
00:18:17.599 --> 00:18:22.960
that I want to just highlight is
you're telling me that basically, you put

222
00:18:22.000 --> 00:18:26.839
a better engine in my car,
and I don't have to do anything special

223
00:18:26.920 --> 00:18:32.920
other than upgrade react in order to
get the get the more horsepower. Right,

224
00:18:32.960 --> 00:18:37.400
I don't have to turn anything on
or jump through some hoops or you

225
00:18:37.440 --> 00:18:42.720
know whatever. Right, Yep,
that's the idea. And obviously it's still

226
00:18:42.720 --> 00:18:47.400
experimental, so you know, like
maybe maybe keep driving with the current engine

227
00:18:47.440 --> 00:18:48.839
for right now, you know,
give us try it out, give us

228
00:18:48.880 --> 00:18:52.440
feedback. But yeah, the idea
is that, right, that's that's what

229
00:18:52.440 --> 00:18:56.039
we're going for. That's good to
know because then I don't get frustrated by

230
00:18:56.079 --> 00:19:00.240
the oh this it's not doing exactly
what I expect. But the other the

231
00:19:00.279 --> 00:19:03.480
other piece of it is is that
you talked about kind of the two layers

232
00:19:03.519 --> 00:19:11.519
of what dominipulation or compilation or whatever
that the react already did to react to

233
00:19:11.680 --> 00:19:17.920
changes. And it sounded like you
were saying that you've optimized the one layer,

234
00:19:18.640 --> 00:19:21.359
but because of the way that it's
optimized, right, so you have

235
00:19:21.480 --> 00:19:22.960
the this is the stuff that needs
to go on the page, and then

236
00:19:23.200 --> 00:19:26.759
this is how we're going to manipulate
the virtual dom to get it on the

237
00:19:26.799 --> 00:19:32.119
page. You optimize this layer with
the you know, putting it on the

238
00:19:32.200 --> 00:19:34.039
virtual dom or did I get that
wrong? No, you got it reversed.

239
00:19:34.359 --> 00:19:40.039
They got reversed from the get go. The mechanism that got the virtual

240
00:19:40.079 --> 00:19:44.839
dome to the dome was highly optimal. It identified what changed in the virtual

241
00:19:44.920 --> 00:19:48.720
dome right, and then updated only
those things in the dome that actually needed

242
00:19:48.799 --> 00:19:53.960
updating. And to be honest,
that's the most expensive thing per update,

243
00:19:55.759 --> 00:20:03.200
because the dome is expensive. But
what was missing was the optimization to the

244
00:20:03.319 --> 00:20:10.720
user land code that generated the virtual
dom itself to you know, the higher

245
00:20:10.839 --> 00:20:15.319
level. Okay, but but it
trans because you've optimized I guess I had

246
00:20:15.519 --> 00:20:19.400
one layer here in one layer.
Because you optimize this layer, it translates

247
00:20:19.400 --> 00:20:25.119
into better performance here because it doesn't
have to do as much work. Yeah.

248
00:20:25.160 --> 00:20:30.000
So, yeah, exactly, so
we are so Reactors actually always had

249
00:20:30.000 --> 00:20:33.920
an optimization that most developers don't take
advantage of, which is that when we

250
00:20:34.240 --> 00:20:37.640
when you you know, return you
know, some js X from your from

251
00:20:37.680 --> 00:20:42.880
your component, we compare you know, the basic idea of what react is

252
00:20:42.920 --> 00:20:48.400
doing this that in order to find
the minimal dom updates is reconciling. Okay,

253
00:20:48.400 --> 00:20:51.240
you return this new JSX telling us
what the UI should be. We're

254
00:20:51.240 --> 00:20:53.519
going to compare it to the previous
JSX what the u I was, and

255
00:20:53.559 --> 00:20:56.799
we're going to figure out the difference. And so one of the you know,

256
00:20:57.039 --> 00:21:00.799
built in optimizations there is that if
the if it's the exact same JSX

257
00:21:00.839 --> 00:21:03.279
element. At a particular point,
we can say, ah, okay,

258
00:21:03.319 --> 00:21:07.039
that entire subtree. You know,
it doesn't have to change unless it had

259
00:21:07.079 --> 00:21:08.640
its own like state updates or something. But we can just kind of skip

260
00:21:08.680 --> 00:21:14.240
that subtree and look at the rest, right, And so what what the

261
00:21:14.279 --> 00:21:17.799
compiler's doing is taking advantage of that
and kind of finding all the bits of

262
00:21:17.839 --> 00:21:19.799
the GSX that don't need to update. We're not passing a new prop to

263
00:21:19.839 --> 00:21:23.680
that component. So we'll just reuse
that entire JSX element, and now React

264
00:21:23.680 --> 00:21:30.400
can actually skip diffing that element.
So it's actually doing less it's like doing

265
00:21:30.480 --> 00:21:33.079
less rendering work, but it's also
then creating less work to do in the

266
00:21:33.079 --> 00:21:37.839
diffing process as well. I'll get
back to that because that's a really interesting

267
00:21:37.920 --> 00:21:42.319
point that I hadn't thought about and
hadn't considered. But I think, in

268
00:21:42.400 --> 00:21:48.319
a sense, a lot of the
optimization is actually based around mammoralization. I

269
00:21:48.359 --> 00:21:52.279
think it might be worthwhile to spend
a couple of minutes in explaining what mammoralization

270
00:21:52.480 --> 00:21:59.960
actually is and what it means.
Yep, yeah, yeah, I can

271
00:22:00.039 --> 00:22:07.400
of it. I think the main
problem that we're solving it memorization is davascript's

272
00:22:07.160 --> 00:22:12.599
referential equality is if you create new
objects and compy them, they're not equal

273
00:22:12.960 --> 00:22:17.920
even if they have the same values
in them. Only primitives can be compared.

274
00:22:18.279 --> 00:22:23.200
That's that's the problem that breaks down
with this theffing that Jege is stopped

275
00:22:23.200 --> 00:22:32.359
about. So with memmorization we keep
as long as the values don't sematically change,

276
00:22:32.519 --> 00:22:34.599
like the values in them don't change, the objects are the same.

277
00:22:37.200 --> 00:22:42.640
So basically you're saying, if if
if I have a function, if I

278
00:22:42.680 --> 00:22:48.359
have a function that's a pure function
that to make it simple, it takes

279
00:22:48.440 --> 00:22:52.960
a couple of parameters, does some
computation, and returns the result. I

280
00:22:53.119 --> 00:22:59.559
don't need to run this function again
if the parameters haven't changed, because there's

281
00:22:59.599 --> 00:23:04.079
a gara and that the result would
be the same. And and by remembering

282
00:23:04.119 --> 00:23:11.160
the previous result, not only am
I avoiding the computation of running the function

283
00:23:11.279 --> 00:23:15.960
again, I'm also gaining the value
of referential equality because I'm using the exact

284
00:23:17.079 --> 00:23:22.079
same output value reference, so I
don't need to do a deep comparison on

285
00:23:22.119 --> 00:23:26.279
the result. I can just look
at the actual reference. So I benefit

286
00:23:26.519 --> 00:23:32.839
twice, as it were, from
from avoiding this recalculation. Yeah, and

287
00:23:32.880 --> 00:23:36.680
there's a there's a cascading aspect to
this, right, So if you imagine

288
00:23:36.720 --> 00:23:42.160
that state changes, you know,
so you update state and you change like

289
00:23:42.160 --> 00:23:47.039
an account from zero to one,
and then you put that count inside of

290
00:23:47.039 --> 00:23:49.279
an array for some reason, right, And now every time you render that,

291
00:23:49.279 --> 00:23:52.920
we're producing a new array. And
now you use that array for some

292
00:23:53.000 --> 00:23:56.839
other calculation, and so now you're
you're looking at okay, right, so

293
00:23:56.960 --> 00:24:00.200
you started with just a single number
changing, Now you've that inside of an

294
00:24:00.240 --> 00:24:03.480
object or an array. Maybe you
then capture that inside of a function,

295
00:24:04.000 --> 00:24:10.440
right to log that array. And
so without memoization, what's kind of happening

296
00:24:10.480 --> 00:24:12.799
again, like the default and react
just every time we render, reproduce a

297
00:24:12.880 --> 00:24:18.359
new new state, new array,
new object, capturing that new new function

298
00:24:18.759 --> 00:24:22.799
logging it. With memorization, the
idea is to say, okay, if

299
00:24:22.839 --> 00:24:26.200
the input didn't change, we're going
to produce the same output. But now

300
00:24:26.519 --> 00:24:29.559
if you kind of only do that
at one step, it doesn't really help.

301
00:24:29.720 --> 00:24:32.400
Right If you say, oh,
like if the array didn't change,

302
00:24:32.440 --> 00:24:34.640
don't produce the new function, Well, the array changes every time, so

303
00:24:34.680 --> 00:24:37.640
that that didn't really help, right. The idea is that with memoization,

304
00:24:37.920 --> 00:24:41.359
it needs to kind of be every
single step of the way, or else

305
00:24:41.400 --> 00:24:45.559
you get a cascade if you forget
one step in that process. Now that

306
00:24:45.680 --> 00:24:48.880
that will always produce a new result. Now the next stage that is trying

307
00:24:48.880 --> 00:24:52.440
to memoize will say, oh,
well, my input or ray changed.

308
00:24:52.480 --> 00:24:56.000
What am I going to do?
I guess I have to recalculate and reproduce

309
00:24:56.000 --> 00:24:59.799
this function or something. And so
then you get an entire subtree kind of

310
00:24:59.799 --> 00:25:03.440
on necessarily updating. And so the
idea is that with memoization, one way

311
00:25:03.480 --> 00:25:06.319
to think about it is automatic memorization. Another way to think about it is

312
00:25:06.359 --> 00:25:08.920
kind of tuning the amount of reactivity. What we're doing is making it so

313
00:25:08.920 --> 00:25:14.960
that when values semantically change, we're
updating, and otherwise we're not. We're

314
00:25:15.000 --> 00:25:18.400
not updating. And so that's that's
the thing that got Soathia is trying to

315
00:25:18.400 --> 00:25:19.160
get with. Like, I think
that the way you're getting it with referential

316
00:25:19.240 --> 00:25:25.079
quality, right is referential equality is
kind of a stand in for did this

317
00:25:25.240 --> 00:25:29.240
meaningfully change, because that's the only
kind of way we have to kind of

318
00:25:29.240 --> 00:25:32.519
to check did it meaningfully change?
Otherwise you actually got to do a full

319
00:25:32.559 --> 00:25:36.519
diff of the object, and unfortunately, you can't diff functions in JavaScript,

320
00:25:37.440 --> 00:25:41.079
So right, we're kind of just
limited by the language there. So just

321
00:25:41.160 --> 00:25:44.920
again to clarify to our listeners,
So who might not be familiar with the

322
00:25:45.039 --> 00:25:48.039
terminology. Let's say, you know, when you're looking at the primitive value

323
00:25:48.279 --> 00:25:53.319
like number Boulian or even a string
in JavaScript, you're just comparing it,

324
00:25:53.359 --> 00:25:57.319
and JavaScript does it for you.
So you know, seven is equal to

325
00:25:57.359 --> 00:26:02.160
seven hello, and zequal to hold
on. But when you've got a reference

326
00:26:02.200 --> 00:26:07.119
to an object, there are two
types of equality here. One is that

327
00:26:07.359 --> 00:26:14.799
we've got two references to the exact
same object, and the other is that

328
00:26:15.160 --> 00:26:19.920
it's there are two objects, but
they are equivalent. They have the same

329
00:26:21.039 --> 00:26:26.319
values for all the properties. And
again it might be is whether you go

330
00:26:26.440 --> 00:26:30.799
through that object recursively or just one
level down it. You know, the

331
00:26:30.880 --> 00:26:37.240
problem obviously isn't that simple. So
the easiest thing to do in JavaScript,

332
00:26:37.279 --> 00:26:42.240
because that's built in, is referential
equality, which means that both variables are

333
00:26:42.279 --> 00:26:47.960
referencing the exact same object. Then
you just use a comparison operator and it

334
00:26:48.039 --> 00:26:52.119
works. But if you want a
value comparison, you need to do some

335
00:26:52.200 --> 00:26:56.839
sort of a deep comparison, like
the low dash is equal. For those

336
00:26:56.960 --> 00:27:02.519
of us who remember that. And
it's expensive because it goes recursively through the

337
00:27:02.559 --> 00:27:07.559
object and it has to safeguard against
cyclic links and stuff like that. It's

338
00:27:07.599 --> 00:27:14.000
not cheap. So what you're saying
is, when I memoize, then I'm

339
00:27:14.079 --> 00:27:18.160
guaranteed not only to get the result
which is the same object in terms of

340
00:27:18.200 --> 00:27:23.559
its values, I'm guaranteed to get
the exact same object instance. Hence I

341
00:27:23.599 --> 00:27:30.039
can use the very cheap referential equality
that's built into JavaScript exactly. Yep.

342
00:27:30.079 --> 00:27:36.039
Now, one more thing before we
move on from there. Again, if

343
00:27:36.039 --> 00:27:41.680
we go back to the existing primitives
that are in React, we've got memo

344
00:27:41.960 --> 00:27:45.319
and use memo. Can you briefly
explain like what they are and the differences

345
00:27:45.319 --> 00:27:56.119
between them, because I gather that
the React compiler effectively replaces both. Yeah,

346
00:27:56.279 --> 00:28:03.000
So react to memo is to wrap
your component. It's so that when

347
00:28:03.720 --> 00:28:06.880
as long as the props don't change, the component doesn't re render it.

348
00:28:07.240 --> 00:28:11.119
The default be able to React is
if your parent renders, then we re

349
00:28:11.119 --> 00:28:15.759
render the child component even if the
props don't change. So that's that's the

350
00:28:15.799 --> 00:28:21.799
React of memo and use memo is
if any of the dependencies of the use

351
00:28:21.839 --> 00:28:25.599
memo change then we run a computation. Otherwise we use the cash value of

352
00:28:25.680 --> 00:28:32.160
computation that the use memo is run. And I have to say that again,

353
00:28:32.200 --> 00:28:37.839
as a long time React developer,
I've encountered a lot of code where

354
00:28:37.960 --> 00:28:45.559
somebody added use state to a top
level component that for some you know,

355
00:28:45.960 --> 00:28:52.480
you know, maybe let's say some
button click or something, and then you

356
00:28:52.519 --> 00:29:00.680
know that thing causes a rerender of
the effectively the entire application for no good

357
00:29:00.720 --> 00:29:06.680
reason. So the fix against that
was to use well and ideally you might

358
00:29:06.880 --> 00:29:08.920
well, you could do two things. You could either move that button into

359
00:29:10.039 --> 00:29:15.920
its own subcomponent, which well,
it's easy to do but sometimes felt like,

360
00:29:17.200 --> 00:29:22.359
you know, unnecessary overhead on the
developer. The other alternative was to

361
00:29:22.559 --> 00:29:32.559
memorize all the subcomponents. But then
people either memoize too much or too little,

362
00:29:32.559 --> 00:29:36.039
and when they memorized too much,
they showed the wrong things, and

363
00:29:36.119 --> 00:29:40.240
when they memoized too little, then
they you know, they didn't get the

364
00:29:40.279 --> 00:29:45.559
performance benefits. And what I've seen, what I actually often see is that

365
00:29:45.640 --> 00:29:51.480
in many applications, either they don't
memorize anything and they often don't even realize

366
00:29:51.480 --> 00:29:53.920
that they have a problem, because
you know, it works it's kind of

367
00:29:53.960 --> 00:30:03.400
slow, but it works, or
they memorize everything and the whole application is

368
00:30:03.559 --> 00:30:07.759
just a million calls to memo.
Yep, that's that's exactly the type of

369
00:30:07.839 --> 00:30:11.640
thing we've seen. And to be
clear, like a lot of times for

370
00:30:11.319 --> 00:30:15.920
especially for smaller applications, the fact
that there aren't isn't a lot of memization

371
00:30:15.079 --> 00:30:18.880
is fine. Like the amount of
revendering that you're doing just can be fine.

372
00:30:18.880 --> 00:30:21.559
We hear, we've actually it's funny
like and then we hear a lot

373
00:30:21.599 --> 00:30:26.759
about the places where people run into
performance problems, but we don't hear about

374
00:30:26.799 --> 00:30:30.000
the cases that are basically fine.
And so you know, one of the

375
00:30:30.000 --> 00:30:33.079
things that the React comp that was
was interesting was just going on talking people

376
00:30:33.160 --> 00:30:34.640
and people are saying, like,
I love React. It's it's so fast,

377
00:30:34.759 --> 00:30:37.880
you know, I never have performance
problems. It's like, oh,

378
00:30:37.880 --> 00:30:40.799
that's so nice to hear, but
like you know that we're not content with

379
00:30:40.839 --> 00:30:41.400
that, but it's still great to
hear. Right, we want to make

380
00:30:41.440 --> 00:30:45.640
we want to make every React app
fast by default, but but yes,

381
00:30:47.960 --> 00:30:49.279
like the need to do this kind
of memization that that is like that is

382
00:30:49.319 --> 00:30:55.359
overhead that we can solve, right
that that's like that having to kind of

383
00:30:55.480 --> 00:30:57.759
and the worst part is that if
you add you know, you could go

384
00:30:57.759 --> 00:31:02.759
through a lot of trouble to add
memosation everywhere, but it's still easy to

385
00:31:02.799 --> 00:31:07.240
miss one spot right and then like
as I said, like that can then

386
00:31:07.240 --> 00:31:11.119
cause a cascade because you missed one
memoization. So that produces a new value,

387
00:31:11.559 --> 00:31:14.440
and then that new value flows into
the memoization you have, which then

388
00:31:14.480 --> 00:31:17.720
says, oh about my input change, I have to recalculate, and then

389
00:31:17.759 --> 00:31:21.880
that kind of causes a cascade.
And so missing a single memoization right can

390
00:31:21.960 --> 00:31:25.400
kind of defeat all your your optimizations. And that's very easy to have happen

391
00:31:25.440 --> 00:31:27.920
when you're you know, changing the
code over time. You had you were

392
00:31:27.960 --> 00:31:33.359
passing one callback and you memoized it. Now somebody adds an extra callback and

393
00:31:33.400 --> 00:31:36.440
they forget to memoize it, and
oops, there you go, right,

394
00:31:37.720 --> 00:31:42.799
So am I correct and understanding that? Essentially what the compiler does is it

395
00:31:42.839 --> 00:31:47.720
goes through all of your code,
find all the places where you should have

396
00:31:47.759 --> 00:31:52.599
put memo or use memo, and
then implicitly inserts them for you. Does

397
00:31:52.640 --> 00:31:59.839
it also do other things or does
it do something different? Or what it's

398
00:31:59.880 --> 00:32:08.039
like automatic semi colon insertion except cooler
right. Well, that that actually brings

399
00:32:08.119 --> 00:32:13.240
up the point that I wanted to
ask, is it seems like this is

400
00:32:13.319 --> 00:32:16.759
the type of magic that we need. But why not put it in the

401
00:32:16.839 --> 00:32:22.680
hands of the user, like you
know, a linter. For me,

402
00:32:22.759 --> 00:32:27.599
personally, I prefer explicit over implicit, and I prefer to work with like

403
00:32:28.240 --> 00:32:32.119
with the fewest layers of abstraction,
because you can't understand there's too much abstraction

404
00:32:32.200 --> 00:32:36.079
in modern software. You know,
Jonathan Blow and Casey Morty and all these

405
00:32:36.079 --> 00:32:39.400
guys are talking about this stuff primagen
et cetera. You know, like the

406
00:32:39.440 --> 00:32:44.160
abstraction has become so great that just
people just they have no idea what's going

407
00:32:44.200 --> 00:32:47.559
on. But you know, we
have a lot of great tools, But

408
00:32:47.759 --> 00:32:52.319
what if we could just surface it
at the user level where it is a

409
00:32:52.440 --> 00:32:58.240
linter thing or like an auto formatter
thing like automatic semicle insertion, like hey,

410
00:32:58.400 --> 00:33:01.960
you should use memo here, or
just like I hit save and then

411
00:33:02.039 --> 00:33:06.079
boom, they use memo appears and
I changed the code and I hit save

412
00:33:06.160 --> 00:33:08.279
and boom, the use memo disappears
because it's not relevant. Like, if

413
00:33:08.279 --> 00:33:14.799
you've got that information, why not
surface it to the developers so that they

414
00:33:14.839 --> 00:33:22.240
can learn and grow and not be
like pushed down behind more abstraction on something

415
00:33:22.279 --> 00:33:25.240
that's already like they're crushing under the
weight of it. I have my opinion

416
00:33:25.279 --> 00:33:29.880
on that, but I'll let the
guys answer first, if they have an

417
00:33:29.920 --> 00:33:37.960
answer. Joe, I'm actually you
just yeah, so I think there's a

418
00:33:38.319 --> 00:33:42.759
Okay, I guess uh, I
guess I disagree with the with the premise

419
00:33:42.880 --> 00:33:49.880
somewhat that there's too much abstraction.
You know, we don't what Yes,

420
00:33:50.039 --> 00:33:57.480
that's not controversial, broke right,
So when when you when you start your

421
00:33:57.480 --> 00:34:00.240
next project, you write your own
database, you were an operating system,

422
00:34:00.319 --> 00:34:04.240
You implement your own programming language,
you write your own text editor, you

423
00:34:04.240 --> 00:34:07.160
write your own graphics engine. You
do all those things before you can build

424
00:34:07.160 --> 00:34:12.000
your next blog. Right, Like
that was just last thing. I'm just

425
00:34:13.000 --> 00:34:15.519
I know that you're I'm just like
for the audience sake of like, like

426
00:34:15.679 --> 00:34:17.559
there's clearly like a certain level of
abstraction that's like that's kind of necessary.

427
00:34:17.679 --> 00:34:21.960
So to me, it's really about
the value of a particular abstraction, right,

428
00:34:22.039 --> 00:34:24.920
Like, I definitely hear what you're
saying, Like there are some abstractions

429
00:34:24.920 --> 00:34:28.559
that don't pay their weight, right, and and in particular, I think

430
00:34:28.639 --> 00:34:31.719
like the bane of our of like
software to pulpers existence is like leaky abstractions

431
00:34:32.079 --> 00:34:37.519
right where it's you're like, it
almost works, but it doesn't always work.

432
00:34:37.559 --> 00:34:40.599
And that's I think where those are
things that kind of can be too

433
00:34:40.639 --> 00:34:45.159
magical and debugging them. So go, ah, let me let me just

434
00:34:45.760 --> 00:34:52.280
to your example, I want to
add something clarifying vs code to JavaScript file

435
00:34:54.239 --> 00:34:59.519
perfect like, this is a good
abstraction. It's perfectly understandable that it's one

436
00:34:59.559 --> 00:35:05.000
to one. It's a non leaky
abstraction, right, okay, Microsoft word

437
00:35:05.519 --> 00:35:08.559
to JavaScript. I mean like now
you've got to deal with the smart quotes.

438
00:35:08.599 --> 00:35:14.079
You got to do special pasting,
like very bad abstraction, good for

439
00:35:14.199 --> 00:35:19.280
a particular purpose, right, But
like so there's a difference between saying oh,

440
00:35:19.719 --> 00:35:23.480
like because the editor you can perfectly
understand, there's no confusion about what

441
00:35:23.559 --> 00:35:28.400
happens at vs code when you hit
save, like the file you get it

442
00:35:28.599 --> 00:35:31.079
like so, yes, there's a
lot of abstraction there and it might take

443
00:35:31.119 --> 00:35:36.679
fifteen minutes to load, but once
it's loaded, you hit save, like

444
00:35:36.880 --> 00:35:40.599
you get the thing that you expected
and there's not like this burden of hotly

445
00:35:40.639 --> 00:35:45.400
crap. How did this file end
up here? Yeah, So so the

446
00:35:45.480 --> 00:35:47.039
other aspect is then so then the
question for me is like, is it

447
00:35:47.079 --> 00:35:51.840
a leaky abstraction? Right? Is
the abstraction sound? Can you rely on

448
00:35:51.840 --> 00:35:53.039
it? Is there? Can you
build up a clear mental model of what

449
00:35:53.079 --> 00:35:57.800
the compiler's doing? And that's what
we really exactly, So that's what we've

450
00:35:57.840 --> 00:36:01.440
really focused the model. So the
so there's a so there's kind of the

451
00:36:02.159 --> 00:36:06.719
mental model aspect and then the pragmatic
aspect of and we kind of have to

452
00:36:06.719 --> 00:36:09.639
balance these two things. So on
on the practical side, imagine that we

453
00:36:09.679 --> 00:36:16.199
did, say a providal linter that
would add memoization in our analysis we've seen

454
00:36:16.480 --> 00:36:20.199
I don't I don't know if I
can share the number. Uh. The

455
00:36:20.199 --> 00:36:25.840
compiler adds a lot more memoization,
Like it memoizes things that developers would never

456
00:36:25.880 --> 00:36:29.960
in a million years of thought to
memorize, right, like every single individual

457
00:36:30.000 --> 00:36:34.400
JSX expression getting independently memoized and then
attempting to be very smart about how it

458
00:36:34.440 --> 00:36:37.000
groups those together, right, because
they can figure out, oh, you're

459
00:36:37.039 --> 00:36:39.199
just creating JSX and so like one
of the things working in now is kind

460
00:36:39.239 --> 00:36:42.880
of starting to reorder the instructions.
We can say, oh, these these

461
00:36:42.960 --> 00:36:46.320
three things all depend upon the same
input. Let's recreate them together because you,

462
00:36:46.400 --> 00:36:51.079
as a developer can't observe when that
code runs, so it's more efficient

463
00:36:51.119 --> 00:36:55.599
to group them together. Now that
like rewriting that like, but that that

464
00:36:55.679 --> 00:37:00.239
transformation might not be the most readable
way to actually look at that code.

465
00:37:00.639 --> 00:37:04.960
Right. So that's where on the
practical side, you know, if we

466
00:37:05.039 --> 00:37:07.719
were to do this, the things
we'd be suggesting to you as like here

467
00:37:07.840 --> 00:37:10.880
go you know, change your code
to be like this. That might not

468
00:37:10.920 --> 00:37:15.840
be readable, that might not be
very editable. And so instead having letting

469
00:37:15.880 --> 00:37:19.199
the developer not have to worry about
that, not to mention, you know,

470
00:37:19.239 --> 00:37:20.960
you go to edit your file and
you're like, okay, do I

471
00:37:20.960 --> 00:37:22.519
put can I is it safe to
put this over here? Do I have

472
00:37:22.519 --> 00:37:25.239
to put it inside the use memo? Where does this code go? It's

473
00:37:25.280 --> 00:37:29.679
a lot easier to think about just
writing your code the way it makes sense.

474
00:37:29.719 --> 00:37:35.480
And j before before you interrupt again, based on my experience and and

475
00:37:35.480 --> 00:37:38.480
and Joe was going exactly where I
wanted to go. Is the fact that

476
00:37:39.039 --> 00:37:44.719
memoization for me is a lot of
line noise. Even if if the compiler

477
00:37:44.880 --> 00:37:49.039
wasn't doing all the sophisticated things that
Joe just described, even if it was

478
00:37:49.199 --> 00:37:53.480
just adding relatively simple use memo and
memo codes without moving the code all over

479
00:37:53.519 --> 00:37:59.119
the place. All those memos and
use memos don't really add anything to the

480
00:37:59.159 --> 00:38:01.880
business logic. There are a lot
of line noise, So if I can

481
00:38:02.960 --> 00:38:07.159
ignore them, if I can remove
them out of the code, the code

482
00:38:07.199 --> 00:38:12.719
becomes clearer and more readable. Like
I said, in the ideal world,

483
00:38:13.119 --> 00:38:19.079
everything would be just uh stay in. They just sets out. You wouldn't

484
00:38:19.079 --> 00:38:22.280
need to worry and think about all
these optimizations. Like I don't have to

485
00:38:22.320 --> 00:38:28.440
think about the reconciled. The reconciliation
it happens for me. Likewise, I

486
00:38:28.519 --> 00:38:31.519
don't want to need to think about
themmalization now. Certainly, if when you

487
00:38:31.599 --> 00:38:37.400
start moving code around and grouping things
and changing the order of things, then

488
00:38:37.760 --> 00:38:43.039
it's totally a new ballgame and you
don't want to be working at at that

489
00:38:43.159 --> 00:38:45.639
level. Yeah, well, yeah, I get that. It's I understand

490
00:38:45.639 --> 00:38:50.559
now. It's a very lossy conversion. It is. It is more similar

491
00:38:50.559 --> 00:38:53.880
to a traditional compiler. It is
doing the fun roll loops. Yeah.

492
00:38:53.920 --> 00:38:58.199
One thing that it comes to mind, just you know, from my background

493
00:38:58.239 --> 00:39:01.960
with you know this or that,
right, is that you know, you

494
00:39:02.039 --> 00:39:08.039
wind up putting a lot of stuff
in to your code that is the bookkeeping

495
00:39:08.079 --> 00:39:13.880
stuff and is not the Hey,
this section of code has this responsibility,

496
00:39:14.039 --> 00:39:16.599
right, And if in my ideal
world, if I'm looking at a class

497
00:39:16.960 --> 00:39:22.119
or you know, a JavaScript function
or something like that, or a JavaScript

498
00:39:22.119 --> 00:39:25.920
file, the only things I want
to see are actually the business of getting

499
00:39:25.960 --> 00:39:30.760
done what I want to get done. And so to me, the appeal

500
00:39:30.800 --> 00:39:36.320
of this is I don't have to
think about the performance management or the memory

501
00:39:36.360 --> 00:39:40.400
management or anything else because that's taken
care of for me, and so I

502
00:39:40.440 --> 00:39:45.280
can just focus on I have a
component that displays this data, or I

503
00:39:45.400 --> 00:39:50.360
have this business logic behind the scenes
that when I get Jason from the server,

504
00:39:50.880 --> 00:39:54.320
it surfaces it in this way because
that's my job. My job shouldn't

505
00:39:54.360 --> 00:39:59.119
be oh, I've got to go
in and make sure that all the eyes

506
00:39:59.159 --> 00:40:01.760
are dotted in the t easier crossed, because that's no fun anyway, And

507
00:40:01.840 --> 00:40:06.719
to be perfectly honest, the computer
probably can do it better. Yeah,

508
00:40:06.760 --> 00:40:10.280
I think memory management is a good
is a good analogy, right, like

509
00:40:10.639 --> 00:40:15.519
we you know, writing something like
C plus plus or or rust or see

510
00:40:15.599 --> 00:40:19.239
like a lower level language where you
have to like malik and free. Right,

511
00:40:19.360 --> 00:40:22.239
Like, that's that's low level details. And there are cases you know

512
00:40:22.320 --> 00:40:25.880
where that like that is critical for
performance. And you know there's definitely use

513
00:40:25.920 --> 00:40:30.440
cases for systems languages for sure,
when we're writing you know, high level

514
00:40:30.440 --> 00:40:32.920
application with UI logic, that really
just starts to get in the way,

515
00:40:34.159 --> 00:40:37.719
especially when we have these very you
know, UIs are very dynamic, right,

516
00:40:37.760 --> 00:40:39.840
like the lifetime of a value is
it is very hard to think about

517
00:40:40.480 --> 00:40:44.280
because you know, like, okay, that this thing is going to get

518
00:40:44.280 --> 00:40:47.000
shown based on all this parent context, and when does it actually get should

519
00:40:47.000 --> 00:40:51.480
get freed. It's way easier to
just say, let let a garbage clutter

520
00:40:51.559 --> 00:40:53.199
deal with that. And I think
it's very similar with the with the memorization.

521
00:40:53.800 --> 00:40:57.920
Now, now I have a question
like a lot of as we said,

522
00:40:57.960 --> 00:41:01.440
a lot of code bases already use
memo and memo inside of them.

523
00:41:01.800 --> 00:41:06.960
Now, ideally I would think that
once I moved to React compiler, I

524
00:41:06.960 --> 00:41:09.840
would literally go through all my code
and just remove all of them. But

525
00:41:10.199 --> 00:41:15.840
that's a chore, so obviously at
least at the beginning. A lot of

526
00:41:15.880 --> 00:41:19.599
code will have memo use memo inside
of it. What do you do with

527
00:41:19.639 --> 00:41:23.280
that? Do you just leave it
there? Do you effectively remove it then

528
00:41:23.400 --> 00:41:30.480
optimize Like ideally I would think that
you would essentially remove it and then optimize

529
00:41:30.519 --> 00:41:35.599
the resulting code. Yeah. We
Yeah, that's exactly what we do.

530
00:41:35.800 --> 00:41:39.079
We ignore the use memos, we
optimize it as well, it doesn't exist.

531
00:41:39.119 --> 00:41:45.119
But you also check that have we
optimized it similar to what the user

532
00:41:45.440 --> 00:41:51.360
has optimized it, like have or
our dependency is different or is it less

533
00:41:51.360 --> 00:41:54.599
fine grand than the user. If
it doesn't match up, then we build

534
00:41:54.639 --> 00:42:00.480
up. So we make sure we
don't change anything and progress and we only

535
00:42:00.519 --> 00:42:09.800
optimize and improve. So yeah,
so it's actually once we are are the

536
00:42:09.880 --> 00:42:15.760
experimental experimental phase, I think it'd
be more safe to like remove the use

537
00:42:15.800 --> 00:42:22.079
call back for the components that the
compiler can safely compile. Oh yeah,

538
00:42:22.119 --> 00:42:25.960
it also takes care of used callback. I forgot about that. Yeah,

539
00:42:27.519 --> 00:42:30.360
yeah, so one of the things
that Yeah, but part of one of

540
00:42:30.360 --> 00:42:35.400
the things we kind of want to
do during the experimental phase is is get

541
00:42:35.480 --> 00:42:37.679
more you know, data from from
you know. This is why we want

542
00:42:37.719 --> 00:42:39.440
to we're starting the working group to
get you know, get get more feedback

543
00:42:39.480 --> 00:42:45.360
from users about Okay, where are
you know are we is the commander generally

544
00:42:45.400 --> 00:42:49.039
able to preserve existing memization? Are
there? Like? Are there patterns where

545
00:42:49.239 --> 00:42:52.079
that where the compiler isn't able to
preserve that existing memorization? And we should

546
00:42:52.159 --> 00:42:55.239
you know, tune the compiler to
be smarter about those cases, right,

547
00:42:55.400 --> 00:42:59.880
because our goal, our eventual goal
is to get to where users don't have

548
00:42:59.920 --> 00:43:04.920
to do manual memorization, hopefully at
all, but definitely in the experimental phase,

549
00:43:04.920 --> 00:43:07.639
we're probably not one hundred percent of
the way there. Uh, and

550
00:43:07.679 --> 00:43:08.800
so we kind of want to get
feedback to kind of tune and and get

551
00:43:08.840 --> 00:43:13.360
and get all the way to that
point. Now you mentioned bailing out.

552
00:43:13.800 --> 00:43:19.679
Can you elaborate a little bit about
that behavior of the compiler? Sure?

553
00:43:19.760 --> 00:43:24.199
Yeah. The so the combiner resumes
that the code follows the rules of React,

554
00:43:24.440 --> 00:43:29.760
right, Like, there are certain
rules that we expect, like props

555
00:43:29.800 --> 00:43:32.639
you communate, props you you must
use the center function to update state.

556
00:43:35.199 --> 00:43:40.280
Hey a j It's like the the
what's it called the rules of Python and

557
00:43:40.920 --> 00:43:45.840
go and and stuff like that.
Python, the zen of Python Go proverbs

558
00:43:45.960 --> 00:43:52.880
and of zig. So we know
we have the Zenov of React. That's

559
00:43:52.239 --> 00:43:57.239
that's good. I need to update
my link of things with the zens because

560
00:43:57.239 --> 00:44:00.360
I think I had What do I
have for that? For React? There

561
00:44:00.400 --> 00:44:02.840
is there are two the React was
React React ration out. There are two

562
00:44:02.840 --> 00:44:07.559
documents for React that I have in
the in the list of the thing is

563
00:44:08.360 --> 00:44:12.159
Now I just feel like going and
meditating on my components for a while.

564
00:44:15.360 --> 00:44:17.760
So what are the rules? I'm
gonna jump us a little bit to the

565
00:44:17.800 --> 00:44:22.159
side because I have to. You
brought it up. What what are the

566
00:44:22.239 --> 00:44:29.000
rules of React? I think the
main one is keep components that we already

567
00:44:29.039 --> 00:44:30.960
know, and all of the other
rules like just fall out of that,

568
00:44:31.880 --> 00:44:38.840
which is don't your props, don't
update the state without the setter function,

569
00:44:39.639 --> 00:44:45.559
don't. And then there are like
sudden like implementation rules like don't call hooks

570
00:44:45.559 --> 00:44:52.760
conditionally use have a US prefix for
your hooks somewhere. That is, we

571
00:44:52.800 --> 00:44:59.519
have a really read documentation page on
all of the rules with examples. We

572
00:44:59.599 --> 00:45:05.079
also have a yes limp plug in
that will catch where you while it also

573
00:45:05.079 --> 00:45:12.679
reacting point to the to the documentation. I think okay, So previously there

574
00:45:12.880 --> 00:45:17.519
was thinking and React React design principles, and then there was a YouTube video

575
00:45:19.599 --> 00:45:28.719
uh React Today and Tomorrow that were
the kind of philosophical documents for React.

576
00:45:28.840 --> 00:45:32.199
So I will try to find Wait, you've got rules of React published?

577
00:45:32.599 --> 00:45:37.000
Yeah, yeah, I just posted
the link to Facebook, YouTube and twitch.

578
00:45:37.519 --> 00:45:42.519
I wish I wish X would do
that, but it doesn't. But

579
00:45:42.639 --> 00:45:46.159
it's for those that are watching live
and are going on, Okay, how

580
00:45:46.159 --> 00:45:49.320
do I find this or how do
I go find the video? It's React

581
00:45:49.360 --> 00:45:54.119
dot dev Slash reference Slash rules.
Yeah, okay, yeah, I'm putting

582
00:45:54.119 --> 00:46:04.559
I'm putting it in the list the
bailouts. Right, So when the the

583
00:46:04.559 --> 00:46:08.519
componer actually has validation to know and
figure out if any of these rules are

584
00:46:08.559 --> 00:46:13.440
being violated, and if it if
they are being violated, then it doesn't

585
00:46:13.440 --> 00:46:19.239
compile the component because it could incorrectly
compile the component if you don't follow the

586
00:46:19.320 --> 00:46:23.920
rules. So that's that's how we
classify. We want to be safe and

587
00:46:23.960 --> 00:46:30.400
we want to only optimize if we
know it's correct. That's that's the idea

588
00:46:30.360 --> 00:46:34.559
of beIN having bailouts. Yeah,
that's the thing I really love. Sorry,

589
00:46:34.840 --> 00:46:37.440
I apologize, Joe. That's just
to have to say that That's the

590
00:46:37.480 --> 00:46:42.320
thing I really love about React compiler
and kind of like one of the big

591
00:46:42.360 --> 00:46:46.079
differences if I'm comparing to other React
technologies, like for example, reacts to

592
00:46:46.159 --> 00:46:52.559
the components, is the fact that
you took an approach of being like very

593
00:46:52.599 --> 00:46:55.239
low resistance, hardly any resistance at
all. Basically, you drop it in

594
00:46:55.719 --> 00:47:00.360
your components are compatible with it,
you just gain the better in a fit.

595
00:47:00.440 --> 00:47:02.800
If they aren't, nothing bad happens. Again, Obviously, as you

596
00:47:02.840 --> 00:47:07.760
said, it's experimental, but I'm
saying once it's released that that's how it

597
00:47:07.760 --> 00:47:13.039
should work. And that to me
is just you know, it's just upside

598
00:47:13.039 --> 00:47:16.119
and no downside. You don't need
to re architect to change stuff. It's

599
00:47:16.400 --> 00:47:23.960
you just gain immediate value. Yeah, And I think it's the it's more

600
00:47:24.039 --> 00:47:28.800
than like yeah that that's been a
really you know, pretty critical piece of

601
00:47:28.800 --> 00:47:31.360
this project is we we don't want
to have to change why people write React

602
00:47:31.400 --> 00:47:35.760
code. We want to just have
something that that works out, you know,

603
00:47:35.760 --> 00:47:37.840
as much as possible out of the
box. That has always been the

604
00:47:37.840 --> 00:47:40.679
goal. You know that to be
clear, there are some ways that you

605
00:47:40.719 --> 00:47:44.280
know, you can you can violate
the rules of reacting, ways that the

606
00:47:44.280 --> 00:47:49.000
compiler doesn't detect. The canonical one
is like put the violation behind a function,

607
00:47:49.079 --> 00:47:52.880
call like write some rite some helper
function that like flagrantly violates the rules,

608
00:47:52.920 --> 00:47:54.119
and call that function. And you
know, so for example, like

609
00:47:54.199 --> 00:47:59.920
modify state inside of a helper function. We don't know that yet problem,

610
00:48:00.960 --> 00:48:04.800
right, but like as as much
as possible, right, we detect that.

611
00:48:04.880 --> 00:48:07.119
You know, you're following the rules, and in general, if you're

612
00:48:07.119 --> 00:48:08.360
if you're breaking the rules, you
will often see that pop up as a

613
00:48:08.360 --> 00:48:12.079
bug, right, Like you go
to add use memo to something and all

614
00:48:12.119 --> 00:48:15.280
of a sudden, it's not updating
as you'd expect. Oh, it's because

615
00:48:15.320 --> 00:48:16.079
you have you know, you have
some bugs. So these are things that

616
00:48:16.079 --> 00:48:20.000
you could have run into at any
time that we're helping to detect. We're

617
00:48:20.000 --> 00:48:22.360
also working on tooling to kind of
there are some things that we can detect

618
00:48:22.360 --> 00:48:24.840
statically. There are others that can
only be detected at run time, and

619
00:48:24.840 --> 00:48:28.840
so we're working on some tooling to
help kind of at run time, right,

620
00:48:28.960 --> 00:48:32.119
kind of like even even like almost
like further than strict mode to help

621
00:48:32.159 --> 00:48:36.679
figure out like, oh, you
know, the inputs to this value didn't

622
00:48:36.760 --> 00:48:40.039
change, but the output did change. Why is that, oh, looks

623
00:48:40.079 --> 00:48:43.480
like you might have a bug and
we can help to pinpoint. So we're

624
00:48:43.519 --> 00:48:45.159
using these tools internally as we roll
out the compiler, and we're hoping to

625
00:48:45.159 --> 00:48:50.519
bring those to open source as well. But the other thing is, you

626
00:48:50.559 --> 00:48:53.119
know, the you know, we
call this React compiler for a reason,

627
00:48:53.280 --> 00:48:58.159
and that it's it's not just about
automimization. This is really you know,

628
00:48:58.519 --> 00:49:01.639
it's it's really two features, right, It's right now it's automamization and the

629
00:49:01.719 --> 00:49:07.119
linting, but it's also it's really
a platform for understanding your code and being

630
00:49:07.159 --> 00:49:09.920
able to change the way it runs, you know, what's happening at run

631
00:49:09.960 --> 00:49:14.920
time, to be more optimal.
So we're also looking at like, okay,

632
00:49:14.960 --> 00:49:17.280
how what else can we do?
What other APIs can we provide where

633
00:49:17.320 --> 00:49:21.960
we can rely on the compiler,
Like do we need a new API for

634
00:49:22.039 --> 00:49:24.840
something or that could the compiler just
do that automatically for you? Right?

635
00:49:25.039 --> 00:49:28.639
So, for example, a lot
of folks have asked about context selectors,

636
00:49:29.800 --> 00:49:34.880
which the idea there being sometimes you
only want to access a small piece of

637
00:49:34.960 --> 00:49:38.880
context, and right now, whenever
the context value changes, we have to

638
00:49:38.920 --> 00:49:43.960
render every component that uses that context
value. So for example, A common

639
00:49:44.000 --> 00:49:47.960
case is like routing. Right,
maybe the one query parameter changes, but

640
00:49:49.159 --> 00:49:52.880
a particular component only cares about like
the domain. The domain didn't change,

641
00:49:52.880 --> 00:49:57.159
So why should we render the component
that cares about domain when the domain didn't

642
00:49:57.239 --> 00:50:00.159
change. And so a lot of
people have asked for a context selector to

643
00:50:00.159 --> 00:50:04.159
say, oh, let's help us
target the updates to the components that where

644
00:50:04.199 --> 00:50:07.639
their actual input data changed. Well, okay, we could provide an API

645
00:50:07.719 --> 00:50:10.719
for that and de developers that have
to adopt it remember to use it in

646
00:50:10.760 --> 00:50:15.119
all the in all the right places. Or we could say, let's have

647
00:50:15.119 --> 00:50:19.400
the compeler do that for you,
right, and so the commander gives us

648
00:50:19.599 --> 00:50:22.239
you know, I kind of it's
a it's a powerful lever for making it

649
00:50:22.280 --> 00:50:24.559
so that developers, you know,
we can just optimize things out of the

650
00:50:24.559 --> 00:50:28.400
box without developers having to think about
it. So I think this kind of

651
00:50:28.400 --> 00:50:30.039
builds on that, like, once
you have this this solid foundation, we

652
00:50:30.079 --> 00:50:35.000
can we can kind of level up
from there. One thing that I would

653
00:50:35.039 --> 00:50:37.639
love to have, I don't know
if it's on your roadmap at all,

654
00:50:37.159 --> 00:50:45.159
would be automatically generating the dependency map
array for use effects. Yeah, this

655
00:50:45.280 --> 00:50:51.719
is something we're thinking about actively,
but it can be tricky. It's the

656
00:50:51.719 --> 00:50:55.480
there are some valid use cases for
not having all of the dependencies in the

657
00:50:55.480 --> 00:51:00.440
area, right, So we're thinking
of new APIs and yeah, in general,

658
00:51:00.440 --> 00:51:04.679
we're thinking about it alternatively. If
somebody, I think, these days

659
00:51:04.719 --> 00:51:09.679
you have to explicitly specify a dependency
at the very least an empty array.

660
00:51:10.440 --> 00:51:15.360
Uh so maybe like in the scenario
if no array is provided at all,

661
00:51:15.480 --> 00:51:20.360
instead of treating it, you know, as a runtime bug, you would

662
00:51:20.400 --> 00:51:24.719
transform it into the correct array as
it were. You know, I don't

663
00:51:24.760 --> 00:51:29.800
know just as well that that's back
to the point I was trying to make

664
00:51:29.840 --> 00:51:35.039
earlier, Right, there's no value
to having the dependency empty array. Right,

665
00:51:35.760 --> 00:51:38.840
Well, no it depend it's not
there, then you would also assume

666
00:51:38.840 --> 00:51:43.320
it and yeah, then the then
you have less clutter in your coat.

667
00:51:44.760 --> 00:51:50.559
Yes, yeah, So so basically
I think this really gets let's get let's

668
00:51:50.599 --> 00:51:53.159
get to the question of what water
effects four and use effect as kind of

669
00:51:54.440 --> 00:52:00.360
it. Dan wrote a great you
know, a series of posts all on

670
00:52:00.400 --> 00:52:04.320
the documentate on the react av doc
site about you might not need an effect.

671
00:52:05.000 --> 00:52:07.920
There's a lot of things that people
reach for effects for that actually have

672
00:52:07.079 --> 00:52:12.639
other solutions. So part of it
is kind of identifying, okay, where

673
00:52:12.760 --> 00:52:15.199
should you just not be using an
effect at all. For example, sometimes

674
00:52:16.159 --> 00:52:20.840
people will do an effect where they'll
kind of look at the propy, they'll

675
00:52:20.880 --> 00:52:22.679
keep some state, they'll look at
the prop and if the prop changes,

676
00:52:22.719 --> 00:52:25.360
they like reset. It's like,
well, they're they're basically doing use memo,

677
00:52:25.400 --> 00:52:30.079
but manually with a second render,
like okay, just use use memo

678
00:52:30.119 --> 00:52:32.079
there for example, or with with
React compiler, you don't even need memo

679
00:52:32.679 --> 00:52:37.079
to do anything at all. There
are a couple of like you know,

680
00:52:37.239 --> 00:52:40.960
really really good use cases for effects. One is kind of creating sort of

681
00:52:42.000 --> 00:52:45.599
custom events like on mount right like
use effect lets you do and sort of

682
00:52:45.639 --> 00:52:51.599
on mount type of event. And
another is synchronizing with synchronizing React state to

683
00:52:51.639 --> 00:52:53.400
some external system. And so what
we're looking at is kind of bund is

684
00:52:53.440 --> 00:52:59.280
really understanding these these specific use cases
where you really need an effect and then

685
00:52:59.360 --> 00:53:02.760
crafting the I there. But you
know, I think, what what's WHATSATIO

686
00:53:02.800 --> 00:53:06.800
is getting at about? Yeah great, yeah, yeah you might not need

687
00:53:06.800 --> 00:53:12.760
an effect. Is that if when
you're when you're writing an effect, there's

688
00:53:12.800 --> 00:53:17.320
there's really are like legitimate use cases
for not listing all the dependencies. And

689
00:53:17.480 --> 00:53:21.320
the problem today is that because you
you know, what you'll do is you'll

690
00:53:21.360 --> 00:53:23.800
you'll add the dependency you array,
You'll list out a couple dependencies and then

691
00:53:24.360 --> 00:53:27.599
I want to skip I want to
skip that one. So you'll you'll do

692
00:53:27.639 --> 00:53:31.199
an lint suppress you know, disabled
rule tell tell tell the react leinner to

693
00:53:31.199 --> 00:53:35.960
stop talking. The problem is now
you you mentioned some other value and by

694
00:53:35.960 --> 00:53:37.599
default we don't catch it. And
so I think that's in case where we

695
00:53:37.639 --> 00:53:42.480
need a better API to say no, I want to explicitly ignore this one

696
00:53:42.679 --> 00:53:45.960
value, but other values should get
automatically captured. So this is the kind

697
00:53:45.960 --> 00:53:47.679
of stuff we're thinking through. It's
like, we're definitely working on it because

698
00:53:47.800 --> 00:53:52.760
we understand that we want to do
better on effects. So two things about

699
00:53:52.800 --> 00:53:54.760
that. First of all, when
you disable the rule, you often disable

700
00:53:54.840 --> 00:53:59.480
it. You usually disabled it for
the entire line, which means that now

701
00:53:59.519 --> 00:54:02.119
if you make other mistakes in that
line, they actually won't get caught.

702
00:54:02.360 --> 00:54:06.960
Exactly right. So that's the problem, right, Yeah, that's problem number

703
00:54:06.960 --> 00:54:09.039
one. Problem number two is that
if you're doing it, you're probably doing

704
00:54:09.039 --> 00:54:14.280
it for the wrong reason. That
is another yes, exactly right, but

705
00:54:14.480 --> 00:54:17.559
there are there are legitimate use cases
for doing that, and that's but that's

706
00:54:17.599 --> 00:54:22.159
something that we really want to work
on a crafted API for it, like

707
00:54:22.199 --> 00:54:25.239
help developers really understand like did you
did you mean to do this or did

708
00:54:25.280 --> 00:54:30.679
you mean to do that other thing? Now, you were talking about the

709
00:54:30.800 --> 00:54:35.920
fact that it's not just a compiler, it's also a linter, and whenever

710
00:54:35.960 --> 00:54:38.760
you bail out, there are appropriate
linter messages. Even I guess when you

711
00:54:38.800 --> 00:54:45.639
don't bail out, you might provide
informative linting messages. To me, that's

712
00:54:45.679 --> 00:54:51.719
almost as valuable as the compiler itself. If I have like a React expert

713
00:54:51.800 --> 00:54:57.079
watching over my shoulder making sure that
I'm writing the code according to the rules,

714
00:54:57.119 --> 00:55:00.960
that's that's a lot of benefit,
especially for you know, smaller teams,

715
00:55:00.000 --> 00:55:05.480
more junior developers, et cetera.
Yep, absolutely, yeah, Well,

716
00:55:05.519 --> 00:55:08.840
and I like the you may cause
problems, Right, it's not just

717
00:55:08.920 --> 00:55:14.679
a hey, this is you know
we prefer two spaces instead of tabs,

718
00:55:14.920 --> 00:55:21.280
right, it's hey, this this
may actually surface bugs. Now, you

719
00:55:21.400 --> 00:55:25.559
mentioned something while back at the beginning
of our conversation which kind of picked my

720
00:55:25.639 --> 00:55:30.360
interest, and I wasn't sure if
I was understanding it correctly or not.

721
00:55:30.039 --> 00:55:37.159
But there's an interesting potential for passing
data as it were, implicitly from the

722
00:55:37.280 --> 00:55:45.360
compiler from that static analysis that compiler
does to the reconciler like kind of behind

723
00:55:45.400 --> 00:55:52.880
the developers back, like is that
something that you actually do or thinking about?

724
00:55:52.239 --> 00:55:57.840
Is there any potential value in that? Or am I just overcomplicating things?

725
00:55:58.920 --> 00:56:01.159
So can you can you describe a
bit more about like what you mean

726
00:56:01.280 --> 00:56:06.840
there? Well, theoretically you could
create some sort of you know, associate

727
00:56:06.960 --> 00:56:12.159
some uh, I don't know,
some hidden property on to the object that

728
00:56:12.199 --> 00:56:19.039
you create, and that tells the
reconciler to behave somewhat differently in certain scenarios.

729
00:56:19.840 --> 00:56:22.199
Yeah, so I think I think
what we've we've kind of thought about

730
00:56:22.199 --> 00:56:30.000
a couple of things in that general
realm. One is that, well,

731
00:56:30.119 --> 00:56:34.679
you know, we talked about how
the comut auto memoizes. But one thing

732
00:56:34.719 --> 00:56:37.280
to note there is that when we
are talking about automimization, we actually don't

733
00:56:37.440 --> 00:56:45.360
add use memo calls. So so
there's we're actually like producing just like an

734
00:56:45.360 --> 00:56:47.679
if an if else block that's kind
of says like if the inputs to this

735
00:56:47.719 --> 00:56:53.400
computation have changed, recompute it otherwise
reuse the cached value. And there's other

736
00:56:53.440 --> 00:56:55.719
things that we can do where we
can say, okay, the user wrote,

737
00:56:55.760 --> 00:57:00.960
for example, a use effect,
but maybe the output of that doesn't

738
00:57:00.960 --> 00:57:02.519
actually have to be a hook call. Maybe it could just be something that

739
00:57:02.559 --> 00:57:06.679
like that does a more targeted update. So these are some of things where

740
00:57:06.719 --> 00:57:13.639
we're looking at around effects. But
I think for the most part, it's

741
00:57:13.960 --> 00:57:16.960
what we're exploring is more Okay,
we once we have a really you know,

742
00:57:17.000 --> 00:57:20.679
a deep understanding of your code and
what you intent, what your component

743
00:57:20.719 --> 00:57:24.280
intends with the intended behavior is,
we can start changing how that works at

744
00:57:24.360 --> 00:57:28.440
runtime more dramatic. So that's like, so the compiler is kind of step

745
00:57:28.559 --> 00:57:31.880
one of we have the existing React
runtime, we're going to use use a

746
00:57:31.880 --> 00:57:36.360
compiler to understand your code and kind
of optimize with the current run time.

747
00:57:37.679 --> 00:57:39.960
Now we have that baseline of compiler
and run time, and now we can

748
00:57:39.960 --> 00:57:44.280
start evolving them together to actually change
the run time and how the run time

749
00:57:44.280 --> 00:57:46.679
works to be more efficient knowing that
we have this compiler to rely on,

750
00:57:47.199 --> 00:57:50.639
right, and maybe it means that
like you know, if there will still

751
00:57:50.639 --> 00:57:53.199
obviously you have to support like if
you have if you have a component that

752
00:57:53.199 --> 00:57:57.480
that violates the rules that we can't
compile. We'll still need a way to

753
00:57:57.480 --> 00:58:00.199
support that, but we can start
optimizing for if you do follow the rules,

754
00:58:00.320 --> 00:58:02.719
can we make that even faster?
So that's kind of where we go

755
00:58:04.000 --> 00:58:07.480
next. But the first phase is
just getting the compilitively stable obviously. Now

756
00:58:07.559 --> 00:58:16.920
another question is currently the input is
valid well, React JavaScript or React typescript

757
00:58:17.159 --> 00:58:22.880
by React, I mean that it
has jsx in it, but it's still

758
00:58:22.920 --> 00:58:29.000
effectively just JavaScript. Are you thinking
of maybe, you know, creating a

759
00:58:29.039 --> 00:58:31.559
React script further down the line?
I mean, you know, we kind

760
00:58:31.599 --> 00:58:38.239
of talked about it before the show
started. That reacts original creator Jordan Walk

761
00:58:39.039 --> 00:58:45.639
actually also created the Reason programming language
and ideally envisioned all the React developers not

762
00:58:45.719 --> 00:58:52.960
only embracing React, but also replacing
their JavaScript with Reason and helps hence solving

763
00:58:53.119 --> 00:59:00.079
all the referential equality stuff because the
Reason is an you know, function in

764
00:59:00.199 --> 00:59:05.960
language with the mutable data structures.
So are you thinking of one day,

765
00:59:06.280 --> 00:59:10.480
maybe you know, somehow instead of
in one fell swoop, like you know,

766
00:59:12.119 --> 00:59:15.880
gradually moving us over to a React
script. Yeah? So, uh,

767
00:59:16.719 --> 00:59:22.519
we think about we think about React
very much as like a programming language.

768
00:59:22.800 --> 00:59:27.599
It has its own kind of semantics. For example, it has concepts

769
00:59:27.599 --> 00:59:35.519
like components and hooks that that obviously
don't exist in JavaScript. H We but

770
00:59:35.599 --> 00:59:38.440
we think that the thing that has
made reacts so successful is that we embrace

771
00:59:38.840 --> 00:59:44.599
JavaScript. Uh And so you know, while we think about the design of

772
00:59:44.719 --> 00:59:50.320
React from a like a programming language
perspective, we we recognize you know,

773
00:59:50.679 --> 00:59:52.639
for example, we we you know, Meta open sourced flow, which is

774
00:59:52.800 --> 00:59:57.639
a really great you know, a
type system for for JavaScript. The community

775
00:59:57.760 --> 01:00:01.239
has overwhelmingly you know, really supported
type script and typescript is an amazing language.

776
01:00:01.239 --> 01:00:04.440
We love it. We're actually the
compiler is written in type script by

777
01:00:04.480 --> 01:00:09.239
the way, so huge fans of
typescript as well. Not really nothing,

778
01:00:09.400 --> 01:00:14.559
go, how dare you? I
know? I know, uh well we

779
01:00:14.559 --> 01:00:17.360
can get into the rest of the
question in a little bit, but but

780
01:00:17.760 --> 01:00:22.519
uh yeah, we really want us
to kind of let support developers, you

781
01:00:22.559 --> 01:00:28.079
know, meet developers where they are, just like you know, Tomatino are

782
01:00:28.119 --> 01:00:31.320
the former manager and director of react
or used to say, always bet on

783
01:00:31.400 --> 01:00:35.679
JavaScript, and I think that's that's
always for us, That's that's always been

784
01:00:35.679 --> 01:00:38.719
a good bet. So yeah,
we while we think about React from a

785
01:00:38.719 --> 01:00:44.159
programming language perspective, We I don't
really foresee us creating a React script.

786
01:00:44.880 --> 01:00:49.400
We have been on the flow side, been experimenting with some custom syntax for

787
01:00:49.519 --> 01:00:52.000
React. So this is like,
you know, specific to flow. You

788
01:00:52.039 --> 01:00:57.519
know, Flow is is is like
kind of helping us explore what like a

789
01:00:57.559 --> 01:01:00.760
first class what these first class concepts
could be if they if they were in

790
01:01:00.840 --> 01:01:05.199
the language. But that is something
that is purely optional. If you use

791
01:01:05.239 --> 01:01:07.719
flow, you can you know,
you can opt into these like components or

792
01:01:07.719 --> 01:01:13.960
hook keywords. But really React is
always going to be about JavaScript and supporting

793
01:01:14.119 --> 01:01:16.199
and supporting JavaScript from you know that
that's that's like, that's a bread and

794
01:01:16.239 --> 01:01:22.840
butter. Another point that I have
to bring up, and we actually kind

795
01:01:22.840 --> 01:01:30.440
of answer that without referring to it
explicitly is signals. Basically, what I

796
01:01:30.519 --> 01:01:37.159
hear from a lot of developers is, you know, why do I need

797
01:01:37.199 --> 01:01:44.599
the compiler to get these fine grain
computations and updates if I can just use

798
01:01:44.760 --> 01:01:51.320
signals instead then get fine grain reactivity. What's your answer to that? Well,

799
01:01:51.320 --> 01:01:54.079
the really simple answer is why rewrite
your application to use signals when you

800
01:01:54.079 --> 01:01:59.719
could get find grain reactivity by just
adopting a compiler I think, you know,

801
01:02:00.159 --> 01:02:04.480
that's a great answer, but you
know the long the long version of

802
01:02:04.480 --> 01:02:07.960
the answer. First off, in
case folks are not familiar with what signals

803
01:02:07.000 --> 01:02:12.320
are, right, signals are the
idea of basically building up a computation graph.

804
01:02:12.360 --> 01:02:17.199
So you write code that creates,
you know, input signals that you

805
01:02:17.239 --> 01:02:21.440
write, you create, you explositly
create, you know, with with APIs

806
01:02:21.480 --> 01:02:25.079
like a create memo or computed right, you create, you define functions where

807
01:02:25.119 --> 01:02:30.719
those functions are accessing other signals or
other computed values, and then you kind

808
01:02:30.719 --> 01:02:34.639
of have either effects or kind of
listeners sort of at the outside that are

809
01:02:34.639 --> 01:02:37.159
saying, okay, whenever one of
my inputs changes, I'm going to take

810
01:02:37.239 --> 01:02:39.719
some take some action on the outside
world like lug or update the you know,

811
01:02:39.760 --> 01:02:43.000
the text value of a dom element
or something like that. So you

812
01:02:43.039 --> 01:02:46.440
have inputs, derived computations and then
sort of outputs to the system. That's

813
01:02:46.760 --> 01:02:52.800
like the rough idea of signals,
but with with these, with signals as

814
01:02:52.840 --> 01:02:55.760
a first class API, your code
is actually a kind of a metaprogram.

815
01:02:57.360 --> 01:03:04.880
You're writing. You're writing code that
is constructing a computation graph. That initialization

816
01:03:04.960 --> 01:03:07.320
code runs once and then you have
the computation graph that is actually running over

817
01:03:07.360 --> 01:03:13.840
time, and so now you look
at your component and there's actually like two

818
01:03:13.880 --> 01:03:15.800
phases going on that you've had to
think about. And so you see things

819
01:03:15.920 --> 01:03:19.760
like, oh, you talk about
people to talk about Oh like, you

820
01:03:19.800 --> 01:03:22.679
can't destructure props, or you can't
do this, you can't do that,

821
01:03:22.320 --> 01:03:28.519
And it's because there are mistakes that
are easy mistakes to make where you're accidentally

822
01:03:28.559 --> 01:03:31.960
accessing a value at the wrong phase
of the program and now reactivity gets lost.

823
01:03:32.519 --> 01:03:36.800
Right. You also to think about
a lot of the a lot of

824
01:03:36.800 --> 01:03:40.880
the kind of signal space frameworks will
distinguish between a true memoized like where you

825
01:03:40.880 --> 01:03:45.559
have a derived computation that's an actual
signal versus something that's just a lambda that's

826
01:03:45.639 --> 01:03:51.239
kind of passing values through. There's
actually a surprising difference there where using an

827
01:03:51.280 --> 01:03:55.360
actual like a proper derived signal might
allow you to get to short circuit reevaluation,

828
01:03:57.239 --> 01:03:59.440
but if you just use a lambda, you don't get that short circuiting

829
01:03:59.440 --> 01:04:01.519
effect. So there's a lot of
subtletyas you have to actually think about when

830
01:04:01.519 --> 01:04:05.199
you when you're writing a program in
this way that you don't have to think

831
01:04:05.239 --> 01:04:10.280
about when you're just writing UI as
a function of state, right, So

832
01:04:10.360 --> 01:04:14.199
the like our kind of idea is
okay. One of the things that has

833
01:04:14.239 --> 01:04:17.239
made React so, you know,
I think so successful and why so many

834
01:04:17.280 --> 01:04:19.800
people, you know, are able
to kind of ramp up on React and

835
01:04:20.119 --> 01:04:25.400
be productive. I have a friend
who just recently learned a program, and

836
01:04:25.760 --> 01:04:29.400
you know, like one week they're
saying, oh, reaction is really complicated

837
01:04:29.440 --> 01:04:30.119
that you know, they just started
looking at it, and then a couple

838
01:04:30.159 --> 01:04:32.440
weeks later like, oh, I
built a UI, Like it works great,

839
01:04:32.440 --> 01:04:34.199
Like I love it, like I
love you state it's so easy,

840
01:04:34.440 --> 01:04:38.880
Like I think there's something very that
that it is very approachable and easy to

841
01:04:38.960 --> 01:04:43.079
understand about the kind of UI as
a function of state, and then we

842
01:04:43.079 --> 01:04:45.880
can just take that and optimize it. So under the hood with React compiler,

843
01:04:46.079 --> 01:04:50.119
we're getting that same kind of fine
grained reactivity. But things like you

844
01:04:50.239 --> 01:04:54.480
just it's normal job ascript values.
You can do things like earlier turn,

845
01:04:54.599 --> 01:04:58.199
you can destructure your props. All
these things that you expect to work still

846
01:04:58.440 --> 01:05:00.519
just work because it it's the same
React, you know, and just under

847
01:05:00.559 --> 01:05:04.360
the hood it's working a bit differently. I think that's really the key.

848
01:05:04.480 --> 01:05:12.199
You've hit the nail on the head
that the key difference between the React way

849
01:05:12.400 --> 01:05:17.679
I would call it and the signal
way is a different approach of thinking about

850
01:05:18.239 --> 01:05:25.639
UI construction. So if I'm just
looking at it from the perspective of which

851
01:05:25.719 --> 01:05:30.159
one is more efficient, which one
is more performant, which one is you

852
01:05:30.199 --> 01:05:34.079
know, it results in fewer lines
of code. I'm kind of missing the

853
01:05:34.119 --> 01:05:42.599
force for the trees. The key
aspect is how do I think about front

854
01:05:42.719 --> 01:05:48.079
end application design and architecture. Some
people prefer to think about it one way,

855
01:05:48.480 --> 01:05:54.000
some people like to think about it
another way. I really like the

856
01:05:54.079 --> 01:06:00.280
React approach of like I said at
the very beginning that in an ideal world,

857
01:06:00.400 --> 01:06:04.159
it's just as you said, Joe, stay in UI out. The

858
01:06:04.239 --> 01:06:14.599
whole UI thing is is just this
effectively functional composition, and that kind of

859
01:06:15.199 --> 01:06:19.000
gets lost with the signal approach,
which is why when people tell me,

860
01:06:19.119 --> 01:06:23.599
hey, like when is react going
to get signals? And even though I

861
01:06:23.599 --> 01:06:27.719
don't work at Meta and so I
can't really speak for you guys, I

862
01:06:27.840 --> 01:06:32.159
say, I bet that never,
because it's just not the React way from

863
01:06:32.199 --> 01:06:36.800
my perspective. Yeah, I will
clarify that, you know just a bit.

864
01:06:38.119 --> 01:06:41.599
I mean, you know, there
is a proposal out to add signals

865
01:06:41.599 --> 01:06:45.559
as a TC thirty nine to to
to to the language. You know,

866
01:06:45.559 --> 01:06:48.679
obviously, if that becomes a standard, right, just just like we have

867
01:06:49.239 --> 01:06:53.760
we now had used to and you
can pass a promise and you know,

868
01:06:53.960 --> 01:06:58.519
use promises with UH. With React, obviously we want to support you know,

869
01:06:58.519 --> 01:07:00.199
built in features of the language,
and so we'd certainly provide a way

870
01:07:00.199 --> 01:07:03.400
to consume you know, the value
of a signal and read it in a

871
01:07:03.440 --> 01:07:09.519
component of So obviously in that sense, what will support signals, right if

872
01:07:09.519 --> 01:07:12.719
they become part of the language,
But in terms of like using them as

873
01:07:12.719 --> 01:07:15.400
a core feature for how to do
state management and updates and React. Yet,

874
01:07:15.559 --> 01:07:17.920
as you said, we don't.
We don't think that that's you know,

875
01:07:17.960 --> 01:07:20.360
really fits in the React way.
And we think that the current React

876
01:07:20.360 --> 01:07:25.280
model of you as a function of
state plain JavaScript values, normal Jobascript idioms

877
01:07:25.320 --> 01:07:28.400
like earlier, turn if else loops, things like that, that that's an

878
01:07:28.440 --> 01:07:31.760
easier way to reason about applications.
And that's where we expect to continue going

879
01:07:31.840 --> 01:07:34.880
with Reacting. All right, I'm
going to jump in here because we're kind

880
01:07:34.880 --> 01:07:36.840
of getting towards the edge of the
end of our time and I want to

881
01:07:36.840 --> 01:07:44.840
be respectful of yours, but I
guess so Earlier I asked, Hey,

882
01:07:44.880 --> 01:07:47.119
so I don't have to do anything
in order to use this, but it

883
01:07:47.119 --> 01:07:50.880
sounds like it's experimental, so I
might have to if I want to try

884
01:07:50.920 --> 01:07:55.280
it now there may be some steps
to trying it, or maybe it's just

885
01:07:55.360 --> 01:07:59.639
within the working group. So if
people want to try it out, how

886
01:07:59.639 --> 01:08:02.599
do they do that? And then
when people hate when I asked this question,

887
01:08:02.639 --> 01:08:06.280
when do you think it's going to
go to the general public? Right?

888
01:08:06.679 --> 01:08:10.559
And then I get that, don't
do me like that, but you

889
01:08:10.599 --> 01:08:13.480
know, and and I don't know
if you know it's like, well,

890
01:08:14.000 --> 01:08:16.640
barring any major hiccups, it's this
or you know anyway however you want to

891
01:08:16.640 --> 01:08:23.760
answer that, right, So I
think, yeah, right now it is

892
01:08:23.760 --> 01:08:27.720
an experndal state. You can NPM
install the babble plug in. It's super

893
01:08:27.760 --> 01:08:31.279
easy to add it to the babble
conflict just at the compilad and it should

894
01:08:31.319 --> 01:08:40.920
just work. And we have We're
still accepting more partners to the working group.

895
01:08:41.680 --> 01:08:44.600
We want really want feedback from the
community. We want to understand how

896
01:08:44.640 --> 01:08:47.760
people are using the compilerad, how
the compiler works outside of meta and get

897
01:08:47.760 --> 01:08:54.119
feedback and improve the compiler to make
it stable. I think it's part of

898
01:08:54.159 --> 01:08:59.560
that. I think it's too early
to say when exactly we'll make it stable,

899
01:08:59.600 --> 01:09:01.840
but I think it depends on the
feedback we get from the working group.

900
01:09:02.359 --> 01:09:08.640
If the feedback is mostly positive,
then it seems like something we'd make

901
01:09:08.920 --> 01:09:12.119
stablesome. Yeah, just to add
on, I think a couple some of

902
01:09:12.159 --> 01:09:15.880
the things that we're thinking about our
the you know, getting feedback from the

903
01:09:15.880 --> 01:09:18.359
community. As Nathia said, we
are working on effects and like that kind

904
01:09:18.399 --> 01:09:23.680
of like ties in a little bit
to that work. The other other big

905
01:09:23.720 --> 01:09:28.920
thing that we're looking at is what
should libraries do. So for example,

906
01:09:28.920 --> 01:09:32.520
if you're publishing a library and you
want that library to be compatible with multiple

907
01:09:32.600 --> 01:09:38.199
versions of React, how should you
Should you pre compile the library? Should

908
01:09:38.199 --> 01:09:41.560
you not pre compile it. Our
current recommendation is to pre compile libraries,

909
01:09:41.600 --> 01:09:45.840
and then developers don't because the general
the general thing is you don't compile your

910
01:09:45.840 --> 01:09:48.920
node modules, right, like I
compile my code with like the settings I

911
01:09:48.960 --> 01:09:53.760
want you you know, the packages
that I like that I bring in like

912
01:09:53.840 --> 01:09:57.399
those developers know how like you know, can can transform their code based on

913
01:09:57.399 --> 01:10:00.199
how they wrote it right, so
you can leave node modules alone. That

914
01:10:00.239 --> 01:10:02.880
also makes builds faster, so it's
kind of win win. So rough ideas

915
01:10:03.720 --> 01:10:08.359
libraries should publish pre compiled code.
But then one of the things we have

916
01:10:08.399 --> 01:10:10.800
to figure out is, Okay,
how does that work with like multiple React

917
01:10:10.880 --> 01:10:14.640
versions, as the compiler changes over
time, as the React runtime changes over

918
01:10:14.680 --> 01:10:15.479
time. So that's one of the
things we have to kind of figure out

919
01:10:15.479 --> 01:10:18.479
is It've really got a good,
really solid strategy in place there so that

920
01:10:18.520 --> 01:10:25.760
everyone can start adopting it across the
ecosystem. Super cool. One thing that

921
01:10:25.800 --> 01:10:28.880
I really missed when I missed that
I want to give a quick shout out

922
01:10:28.920 --> 01:10:31.680
to is the health check script.
So we have a script that will like

923
01:10:32.239 --> 01:10:42.319
if youture from NBM React compiler health
check, it will run the compiler against

924
01:10:42.319 --> 01:10:45.960
your code base and I will like
to say we were successfully able to compile

925
01:10:45.159 --> 01:10:50.119
x amount of components found these libraries. That doesn't work well with the compilers,

926
01:10:50.119 --> 01:10:56.159
so it will give you like a
status of there find that Yeah,

927
01:10:56.359 --> 01:11:00.760
like molpix and definitely uh, you
know, the es len plug in also

928
01:11:00.880 --> 01:11:03.880
experimental, but I think you know, but that one because it's not changing

929
01:11:03.920 --> 01:11:09.000
your output code. Uh, you
know, definitely recommend just like there's basically

930
01:11:09.119 --> 01:11:11.880
no reason not to install that one
and then just give us feedback about it

931
01:11:12.359 --> 01:11:14.720
because that that's something that can really
help you improve your code bass, you

932
01:11:14.720 --> 01:11:19.920
know, starting today. So installation
is just and b m I basically and

933
01:11:20.000 --> 01:11:23.840
adding it to the babel can fig
yep, so mpm I and then add

934
01:11:23.840 --> 01:11:26.560
it to your babel, can fig
add it to your link and FIG And

935
01:11:26.640 --> 01:11:30.239
you know, we've kind of ran
out of time before we ever got to

936
01:11:30.079 --> 01:11:33.239
Rust and Go, so I guess
we will just need to bring you on

937
01:11:33.359 --> 01:11:39.119
some times you want. Yeah,
the real quick answer is we know that

938
01:11:39.119 --> 01:11:43.199
people are moving to alternative build systems
that are that are based in Rust and

939
01:11:43.199 --> 01:11:45.640
Go, like yes, build is
yes, build is awesome, SWC is

940
01:11:45.680 --> 01:11:49.039
great. Oh right, there's ox
C biome right, a lot of like

941
01:11:49.079 --> 01:11:51.119
a lot of you know, a
lot of explosion in the space, which

942
01:11:51.159 --> 01:11:56.119
is really exciting to see. So, uh, it does make it hard

943
01:11:56.239 --> 01:11:58.880
as a tool author trying to produce
something. It's like, okay, how

944
01:11:58.880 --> 01:12:00.239
do we how do we ship this? Like because if we if we write

945
01:12:00.239 --> 01:12:02.279
it and go, then it works
in the y S build that doesn't work

946
01:12:02.319 --> 01:12:05.880
in the other one, there's kind
of no like one way to write it.

947
01:12:06.159 --> 01:12:11.279
So we've started exploring porting the compiler
to Rust, with the idea being

948
01:12:11.319 --> 01:12:13.760
that we can provide a node binding, we can provide a go binding,

949
01:12:13.880 --> 01:12:16.760
we can obviously provide bindings to Rust
based tools. That is, we have

950
01:12:17.279 --> 01:12:20.000
a partial port that's in the repo, so you can go check that out

951
01:12:20.000 --> 01:12:23.720
if you're interested. But that is, you know, on maintain, we've

952
01:12:23.720 --> 01:12:26.960
just kind of done an early exploration. Long term, I can imagine us

953
01:12:27.039 --> 01:12:30.760
you know, finishing that migration,
but for now it's based on typescript so

954
01:12:30.840 --> 01:12:32.680
it works really easily, you know, drop in with Babbel. Thankfully,

955
01:12:32.760 --> 01:12:38.199
most of the tools, things like
next jes for example, Expo, they've

956
01:12:38.199 --> 01:12:41.279
they've already we've already got documentation for
how to use it in those tools.

957
01:12:41.319 --> 01:12:44.680
Even you know, even in for
example next where the default build is using

958
01:12:44.760 --> 01:12:46.960
Rust, we can we can inject
a babble plug in into that process and

959
01:12:47.239 --> 01:12:53.000
it just works. Well. Just
just be careful because you know, Rust

960
01:12:53.039 --> 01:12:56.279
is kind of old news and Zig
is the new hotness, and you wouldn't

961
01:12:56.319 --> 01:13:00.000
want to spend all that effort just
to have to rewrite it again next week.

962
01:13:00.520 --> 01:13:04.279
Yeah, I mean Yeah, So
what I want to say about that

963
01:13:04.359 --> 01:13:10.079
is Hi is a really cool language. It's got some really awesome features.

964
01:13:10.119 --> 01:13:13.399
We've we've on our team, We've
had some some great like a lot of

965
01:13:13.439 --> 01:13:15.840
success with Rust. We use it
internally for a bunch of different a bunch

966
01:13:15.880 --> 01:13:19.880
of different things, especially around build
tools. Really compiler, which I worked

967
01:13:19.880 --> 01:13:24.840
on is written is now written in
Rust. We rewrote from JavaScript to Rust

968
01:13:25.000 --> 01:13:28.079
a while back, and so we
have a lot of familiarity on our team

969
01:13:28.199 --> 01:13:30.640
with Rust as a language. So
that's kind of an obvious choice for us,

970
01:13:30.640 --> 01:13:34.239
in addition to the hype in the
ecosystem. Cool. All right,

971
01:13:34.319 --> 01:13:38.760
Well, I'm gonna push us into
the final segment of the show, which

972
01:13:38.800 --> 01:13:42.560
is our picks, Dan, Why
don't you start us off with picks?

973
01:13:43.720 --> 01:13:46.159
Okay, I don't have a lot
of picks, since this is the second

974
01:13:46.199 --> 01:13:50.119
episode we're recording this week, and
I got you know, I kind of

975
01:13:50.239 --> 01:13:55.960
used some of my picks in our
last in our previous recording, So I've

976
01:13:56.039 --> 01:14:00.199
just got the one. I've been
really on Netflix as recently, you know,

977
01:14:00.319 --> 01:14:04.159
with the quality of the movies they've
been putting out. You know,

978
01:14:04.640 --> 01:14:10.000
I said that the only good thing
I could say about Atlas was that it's

979
01:14:10.039 --> 01:14:14.840
better than Rebel Moon, and I
can't say anything good about Rebel Moon,

980
01:14:15.159 --> 01:14:23.399
So yeah, but now I actually
want I'm in the process of watching Netflix

981
01:14:23.479 --> 01:14:30.359
movie, which I'm finding surprisingly enjoyable
and well made, and maybe i'll finish

982
01:14:30.399 --> 01:14:34.119
it today, I don't know,
maybe so later in the week. It's

983
01:14:34.399 --> 01:14:41.359
Godzilla minus one. Now it's really
surprising to me because I really wasn't expecting

984
01:14:41.439 --> 01:14:45.079
much and I'm not such a big
fan of Godzilla movies, but this one

985
01:14:45.199 --> 01:14:48.760
is really good, at least again
the first half of the movie. And

986
01:14:48.880 --> 01:14:53.720
interestingly, it's good. The fact
that it's good has nothing to do with

987
01:14:53.800 --> 01:15:00.039
Godzilla. The fact that it's good
has everything to do with the protagonist,

988
01:15:00.439 --> 01:15:08.239
the hero of the story, which
is this kid who was a soldier doing

989
01:15:08.560 --> 01:15:13.119
a Japanese soldier during World War Two. He was actually a kame Kazi pilot

990
01:15:13.640 --> 01:15:15.159
and he kind of chickened out.
It was really at the end of the

991
01:15:15.600 --> 01:15:20.000
war, basically like literally the last
couple of days, everybody knew that they

992
01:15:20.000 --> 01:15:26.159
were losing, so he literally just
didn't want to die, and he's living

993
01:15:26.159 --> 01:15:30.079
with the guilt. And there's the
whole thing of Japan after the war and

994
01:15:31.640 --> 01:15:40.239
you know, and the effect of
the nuclear bombs and like rebuilding the country

995
01:15:40.399 --> 01:15:44.640
and walking around with the guilt of
all your friends and family who have died

996
01:15:44.680 --> 01:15:49.000
in your life and stuff like that. And it's much much more interesting and

997
01:15:49.079 --> 01:15:57.000
engaging to me than the actual monster. And that's why I'm enjoying this movie

998
01:15:57.039 --> 01:16:00.720
so much, and I would highly
recommend it again. I'm talking just the

999
01:16:00.720 --> 01:16:03.720
first half of the movie. I
haven't watched a second f And those are

1000
01:16:03.800 --> 01:16:09.720
my things for today, not cool, AJ, What are your picks?

1001
01:16:10.600 --> 01:16:15.840
First pick is motorcycles because my neighbor
let me ride his motorcycle and I really

1002
01:16:15.920 --> 01:16:21.199
liked it, and so I'm thinking
about trying to find some old Beater Cruiser

1003
01:16:21.279 --> 01:16:27.760
to to ride around for myself.
And if anybody's interested in getting a motorcycle

1004
01:16:27.840 --> 01:16:33.680
learners permit, it's it's a lot
easier than the driver's license because there's actually

1005
01:16:33.720 --> 01:16:43.039
a national standard standard body called MSF, the Motorcycle Foundation I think Safety Motorcycle

1006
01:16:43.079 --> 01:16:48.159
Safety Foundation, and they make the
handbook that pretty much all fifty states use.

1007
01:16:49.239 --> 01:16:55.279
So aside from like I don't know, Utah and Alaska that have a

1008
01:16:55.279 --> 01:17:01.960
different BAC level and like Arizona that
I don't know you like, aside from

1009
01:17:02.000 --> 01:17:08.760
a very few niche things that vary
from state to state. Pretty much,

1010
01:17:08.800 --> 01:17:12.640
if you do any MSF practice test, you can go into your DMV and

1011
01:17:12.800 --> 01:17:16.720
get your Motorcycle Learners Permit, and
then the courses are standardized across the nation

1012
01:17:18.560 --> 01:17:25.520
called BRC for Basic Rider Course,
and then they also have other courses like

1013
01:17:25.560 --> 01:17:30.039
the BRC is basically, if you
take the BRC, you can get your

1014
01:17:30.079 --> 01:17:33.560
license without waiting whatever the time period
is for your learner's permit, and without

1015
01:17:33.600 --> 01:17:40.680
having to do the state exam because
the MSF exam will be done when you

1016
01:17:40.720 --> 01:17:43.520
take the course and it's more rigorous
than the state exam, so you just

1017
01:17:43.560 --> 01:17:48.119
take in your things. So I'm
getting my motorcycle license, so you know,

1018
01:17:48.279 --> 01:17:51.000
as my wife, family and friends
would say, you may never hear

1019
01:17:51.079 --> 01:17:57.800
or see from me again. See
some quiet chuckles in the background there.

1020
01:17:58.439 --> 01:18:04.199
And the other thing that I'll pick
a little self promo again. Webby is

1021
01:18:04.279 --> 01:18:10.000
on the rise. I was just
told recently that it is now an official

1022
01:18:10.079 --> 01:18:16.600
install method for the GitHub Cli and
we're up to one point seven thousand stars,

1023
01:18:16.680 --> 01:18:21.680
so we have hit the inflection point. The the line goes up.

1024
01:18:21.760 --> 01:18:28.199
It hit the hockey stick. So
after many years of working on it,

1025
01:18:28.199 --> 01:18:33.760
it's really cool to see it's arrived. I think the reacting counts stars just

1026
01:18:33.920 --> 01:18:42.000
as galaxies. You know the amount
of star Yeah. Yeah. But for

1027
01:18:42.920 --> 01:18:45.560
those who don't know, it's just
a way to install tools that doesn't require

1028
01:18:45.560 --> 01:18:49.159
a package manager and his platform independent, so it can work in Docker,

1029
01:18:49.319 --> 01:18:58.840
Ubuntu, Alpine, Mac BSD and
when many of the tools it's it's a

1030
01:18:58.880 --> 01:19:04.039
web installed dot dev. Okay,
all right, I am gonna throw out

1031
01:19:04.079 --> 01:19:09.359
my picks and then we'll let Satya
and Joe put theirs in. So I'm

1032
01:19:09.399 --> 01:19:13.920
gonna do a pick. This is
a kid's game. It's a Grandpa back

1033
01:19:14.000 --> 01:19:15.359
game. I don't know if y'all
are familiar. No, it's not.

1034
01:19:15.600 --> 01:19:21.000
I thought it was, but it's
not because I'm looking at the the artwork

1035
01:19:21.039 --> 01:19:28.760
for the box anyway. So every
year for Christmas we get the kids,

1036
01:19:29.119 --> 01:19:30.840
each of our kids a game,
a board gamer, a card game.

1037
01:19:31.479 --> 01:19:39.159
And this one's called Sleeping Queens two. So I think I picked Sleeping Queens

1038
01:19:39.239 --> 01:19:43.319
in the past. It's one that
you know, we got for my daughter

1039
01:19:43.359 --> 01:19:47.439
when she was like six, and
it's a really simple game. You can

1040
01:19:47.479 --> 01:19:51.000
play in like fifteen or twenty minutes. I think you can play it up

1041
01:19:51.039 --> 01:19:56.800
to five players, and essentially what
you do is you play different cards,

1042
01:19:56.840 --> 01:20:02.199
and in Sleeping Queens, what you're
doing is your you play the Kings to

1043
01:20:02.239 --> 01:20:06.079
rescue the Queens, and in Sleeping
Queens, you play the Queens to rescue

1044
01:20:06.079 --> 01:20:11.279
the Kings. And then you have
different cards to let you steal cards from

1045
01:20:11.279 --> 01:20:15.239
other players or play extra cards or
draw extra cards and things like that.

1046
01:20:15.359 --> 01:20:19.319
So it's it's really really simple game. And yeah, it's published by Game

1047
01:20:19.399 --> 01:20:26.880
Rights, so uh, anyway,
it's it's a fun game. Our family

1048
01:20:26.920 --> 01:20:30.439
loves Sleeping Queens. Yeah, I
haven't gotten number two yet, but that's

1049
01:20:30.560 --> 01:20:34.079
thanks for the recommendation. Yeah,
so board game weight I always throw this

1050
01:20:34.159 --> 01:20:36.560
in. I don't know if anybody
cares about the board game weights, but

1051
01:20:36.560 --> 01:20:41.199
it gives people a flavor of how
complicated it is. It has a weight

1052
01:20:41.239 --> 01:20:45.720
of one point five, so you
know, and it's a kids game,

1053
01:20:45.760 --> 01:20:50.840
so it's it's a simple game.
It has just enough complexity to make it

1054
01:20:50.880 --> 01:20:56.319
interesting without making it overwhelming for a
six year old or an eight year old.

1055
01:20:56.439 --> 01:21:01.560
So I'm gonna pick that for my
board game. I'll post the board

1056
01:21:01.640 --> 01:21:06.640
game geek listing here a couple of
other things that I'm gonna pick. So

1057
01:21:06.680 --> 01:21:12.760
my wife and I are about to
finish up Star Trek Discovery. We've enjoyed

1058
01:21:12.760 --> 01:21:16.319
the show, I think, and
I feel this about a lot of shows,

1059
01:21:16.600 --> 01:21:19.840
but the first couple of seasons were
better than the last couple of seasons.

1060
01:21:19.880 --> 01:21:24.439
But I mean, the show's been
good show, So I'm gonna pick

1061
01:21:24.479 --> 01:21:30.359
that. And then the other thing
that I've picked up, I think I

1062
01:21:30.439 --> 01:21:33.079
mentioned that I've been using Finch,
which is just a kind of self care

1063
01:21:33.439 --> 01:21:39.520
social app. My wife and kids
all picked it up, and so yeah,

1064
01:21:39.560 --> 01:21:42.760
so then I can send him hugs
and I can keep track of my

1065
01:21:42.800 --> 01:21:45.560
habits and stuff like that in it. But one of the things that I

1066
01:21:45.600 --> 01:21:51.479
picked up about a week and a
half ago is Dual Lingo. And a

1067
01:21:51.520 --> 01:21:55.720
lot of people know what it is. It's free, right, I mean

1068
01:21:55.760 --> 01:22:00.840
it shows me ads periodically, but
whatever, but unless you're practice languages.

1069
01:22:00.560 --> 01:22:05.239
And initially I picked it up because
I've been wanting to learn Japanese, and

1070
01:22:05.279 --> 01:22:11.119
so I picked it up for Japanese, and then I can't remember what it

1071
01:22:11.159 --> 01:22:13.520
was that inspired me, but I
was like, you know, I really

1072
01:22:14.560 --> 01:22:16.439
I really kind of want to pick
up French again, because I took French

1073
01:22:16.439 --> 01:22:19.920
in high school, and so I
added it. And then I was talking

1074
01:22:19.920 --> 01:22:23.800
to somebody else and I mentioned that
I had lived in Italy for two years

1075
01:22:24.560 --> 01:22:30.079
and realized that my Italian's gotten fairly
rusty. And so I basically do three

1076
01:22:30.159 --> 01:22:31.880
lessons a day. I don't do
them all at once because I don't want

1077
01:22:31.920 --> 01:22:35.399
to like confuse my brain, but
you know, I'll do one in the

1078
01:22:35.399 --> 01:22:38.560
morning, and then i'll do one
sometime during the day, and then i'll

1079
01:22:38.560 --> 01:22:42.520
do another one, you know,
in the afternoon evening. And yeah,

1080
01:22:42.520 --> 01:22:45.359
I'm finding that the Italian's coming back
to me. And what's funny is is

1081
01:22:45.399 --> 01:22:50.199
that my Italian vocabulary is very strong
in a couple of areas and not very

1082
01:22:50.199 --> 01:22:54.840
strong in a bunch of other areas. Because when I lived in Italy,

1083
01:22:54.920 --> 01:22:59.640
I was a missionary for the church, and so my religious vocabulary is very

1084
01:22:59.680 --> 01:23:03.960
fairly broad, right, my day
to day living vocabulary is okay, and

1085
01:23:04.000 --> 01:23:09.680
then my vocabulary on all kinds of
other things is just almost non existent.

1086
01:23:10.039 --> 01:23:13.319
And so I've been picking up vocabulary
and learning how to talk about things that

1087
01:23:13.359 --> 01:23:16.720
I haven't really talked about in Italian. So that's been very fun and I'm

1088
01:23:16.800 --> 01:23:23.640
kind of at different levels on each
one, but it's easy. It's anyway,

1089
01:23:23.680 --> 01:23:28.199
I've been very happy with dual Lingo. You can get a Duolingo Plus

1090
01:23:28.279 --> 01:23:31.399
or pro or whatever, and like, if you make a mistake, you

1091
01:23:31.439 --> 01:23:33.840
get a penalty and you lose a
heart and then you have to wait for

1092
01:23:33.880 --> 01:23:35.560
the heart to come back, and
if you pay, you don't have to

1093
01:23:35.560 --> 01:23:40.159
do that, and it doesn't show
you the ads. And I think there

1094
01:23:40.159 --> 01:23:43.279
are some other social aspects that it
adds. But anyway, I've been pretty

1095
01:23:43.279 --> 01:23:47.600
happy with it. I'm happy that
it's free. And yeah, so I

1096
01:23:47.960 --> 01:23:54.359
can order like four things in Japanese
at a restaurant, I can carry on

1097
01:23:54.399 --> 01:23:59.159
a very rudimentary conversation with people in
French. And then yeah, I'm talking

1098
01:23:59.600 --> 01:24:02.600
learning to talk about daily habits like
exercise and stuff in Italian right now.

1099
01:24:02.720 --> 01:24:06.720
So anyway, I'm gonna I'm gonna
pick all of those and throw it over

1100
01:24:06.760 --> 01:24:15.239
the fence to Satya. Well,
the what's the context for the picks?

1101
01:24:15.279 --> 01:24:18.079
So it's just a shout out about
anything you like? Right So you know,

1102
01:24:18.239 --> 01:24:21.760
Dan picked a movie, I picked
a TV show and an app.

1103
01:24:23.399 --> 01:24:27.760
You know, AJ picked web install
dot dev which is more text just whatever.

1104
01:24:29.920 --> 01:24:33.319
Cool. Yeah, I guess I
can do like this both themed one.

1105
01:24:33.920 --> 01:24:38.640
So there's a right now. I
don't know if you've if anyone's familiar

1106
01:24:38.680 --> 01:24:44.920
with the can't call it crockette.
I don't think it's I don't know if

1107
01:24:44.920 --> 01:24:50.079
it's popular and American. I know
of it. I know it's a sport

1108
01:24:50.119 --> 01:24:54.920
that can last a couple of days, right. There are different versions that

1109
01:24:55.159 --> 01:24:59.199
do it. There's there's one that
lasts for like five days, there's one

1110
01:24:59.199 --> 01:25:01.399
that lasts like the entire day,
and then there's one that's like a couple

1111
01:25:01.399 --> 01:25:08.199
of hours long, for like four
hours long. So there's a World Cup

1112
01:25:08.239 --> 01:25:14.840
happening for that for the really shot
version. It just started this weekend,

1113
01:25:15.479 --> 01:25:17.840
and it's happening in the US.
I think they're trying to like make it

1114
01:25:17.880 --> 01:25:25.720
more popper in the US, So
I'm like excited to see how how that

1115
01:25:25.760 --> 01:25:30.359
pans out. I was following the
last World Cup, which was the slightly

1116
01:25:30.359 --> 01:25:33.199
longer one that happened last year,
and I'm from India and I was supporting

1117
01:25:33.239 --> 01:25:39.279
India, and India is generally very
good at this schem and they went all

1118
01:25:39.319 --> 01:25:42.720
the way unto the finals and then
they lost, which is very heart breaking,

1119
01:25:44.800 --> 01:25:48.439
so I'm hoping that they win this
time. So yeah, that's that's

1120
01:25:48.479 --> 01:25:51.720
my pick. And then I guess
also another sport later one is the Euros

1121
01:25:51.760 --> 01:25:57.880
are starting next week. If you're
into footballer but now you're speaking my language.

1122
01:25:58.479 --> 01:26:00.880
Yeah, well you mean, well
not football as long as we're there.

1123
01:26:00.920 --> 01:26:03.800
I don't know if it'll come out
before the show is there or after.

1124
01:26:04.000 --> 01:26:12.800
But the NBA Finals are also happening, right, so I'm in London,

1125
01:26:12.880 --> 01:26:16.680
so after support England for the Euros, I'll be waiting for England too.

1126
01:26:18.640 --> 01:26:24.680
They are also very good. They
are very good. Yeah, so

1127
01:26:24.720 --> 01:26:27.920
those are my picks. I mean, I can't talk. I always support

1128
01:26:27.920 --> 01:26:31.359
Italy. In the last few years, I've been very very disappointed. But

1129
01:26:31.359 --> 01:26:35.039
but England never actually wins, as
I recall, that's true. They went

1130
01:26:35.079 --> 01:26:42.479
to the finals and well everyone yeah, yeah, all right, all right,

1131
01:26:42.680 --> 01:26:46.880
good deal. So, sticking with
the theme of the podcast, for

1132
01:26:46.960 --> 01:26:51.760
those who are curious about compilers,
Robert nischerm Bob Neishrom wrote a great book

1133
01:26:51.760 --> 01:26:57.600
called Crafting Interpreters h It is available
in you know, dead tree form,

1134
01:26:57.880 --> 01:27:01.319
in electronic form. It's also I
think there's a reversion on crafting interpreters dot

1135
01:27:01.359 --> 01:27:06.680
com. Uh, it's it's it's
just a really really great accessible book where

1136
01:27:06.680 --> 01:27:12.079
he basically walks through building the same
an interpreter for a simple kind of imperative

1137
01:27:12.119 --> 01:27:16.920
language marry JavaScript like language, and
he kind of walks through building a sort

1138
01:27:16.960 --> 01:27:23.000
of ast walk interpreter in I think
like Java, and then he does a

1139
01:27:23.039 --> 01:27:27.479
bytecode based interpreter in C. And
I don't know C at all. I

1140
01:27:27.680 --> 01:27:30.279
like just I can just barely read
it and know what's going on, and

1141
01:27:30.359 --> 01:27:33.199
I was. I found it completely
accessible. It's just very very obvious,

1142
01:27:33.760 --> 01:27:38.159
like what's what's happening, so highly
accessib book to kind of understand that the

1143
01:27:38.159 --> 01:27:42.880
basics of what's happening in the compiler
and an interpreter. Now we've got to

1144
01:27:42.920 --> 01:27:46.159
mention the Dragon Book if you want
something that's so inaccessible, right, yeah,

1145
01:27:46.239 --> 01:27:49.680
yeah, if you want something inaccessible, I've never bothered reading the Dragon

1146
01:27:49.720 --> 01:27:57.000
Book. And then I'll also give
a shout out to Sofia has an amazing

1147
01:27:57.039 --> 01:28:01.039
blog and he's actually written about some
like some of the detail so is recompiled

1148
01:28:01.399 --> 01:28:05.479
dot dev right, So check out
Soathia's blog for kind of some more details

1149
01:28:05.479 --> 01:28:11.239
about how the compiler works on the
inside my life is basically the compiler and

1150
01:28:11.279 --> 01:28:15.880
then like being a dad, so
U plus plus one to sleep in Queens

1151
01:28:15.920 --> 01:28:18.000
as a pick. All right,
well, I guess one last question is

1152
01:28:18.039 --> 01:28:21.800
if people want to learn more about
what we talked about with the compiler,

1153
01:28:23.039 --> 01:28:27.399
or you know, maybe they're looking
for Joe or Satia on the Twitter,

1154
01:28:27.680 --> 01:28:31.720
where do they find you? So
I'm on Twitter as E E N underscore

1155
01:28:31.880 --> 01:28:36.239
js uh And for the compiler,
you can go to react dot dev Slash

1156
01:28:36.439 --> 01:28:45.640
learn Slash React Dash compiler and I'm
underscore Chisatia on x oh. Yeah awesome.

1157
01:28:45.720 --> 01:28:48.560
All right, well, thank you
both for coming and talking through this

1158
01:28:48.680 --> 01:28:54.560
with us. We kind of had
to figure our schedules out, but it's

1159
01:28:54.600 --> 01:29:00.520
so fascinating, so yeah, zero