WEBVTT
1
00:00:05.240 --> 00:00:09.839
Hello, everybody, Welcome to another exciting ever episode of javascripts Jabber.
2
00:00:09.880 --> 00:00:11.880
I am Steve Edwards, the host with the face for
3
00:00:12.000 --> 00:00:13.800
radio as you can see in the voice for being
4
00:00:13.800 --> 00:00:17.519
a mine, but I'm still your host with me Today
5
00:00:17.600 --> 00:00:20.000
on the panel, we have mister Dan Shapiro coming live
6
00:00:20.039 --> 00:00:22.359
from tell Abev, Israel. How you doing, Dan, But well.
7
00:00:22.239 --> 00:00:24.839
You know it's hot here as surprise, surprise.
8
00:00:25.559 --> 00:00:27.719
Yeah, we're going back and forth here. It was pretty
9
00:00:27.719 --> 00:00:29.600
warm last couple weeks and now it's a little cool
10
00:00:29.640 --> 00:00:32.600
and cloudy and it's gonna be pretty mellow, so pretty nice.
11
00:00:32.759 --> 00:00:35.039
As we're getting to the end of August, I'm going
12
00:00:35.079 --> 00:00:39.240
to let Dan introduce our special returning guests, So go for.
13
00:00:39.240 --> 00:00:39.560
It, Dan.
14
00:00:39.920 --> 00:00:43.719
Yeah. So I'm really excited about today's guests. We have
15
00:00:43.799 --> 00:00:47.560
two of them, which means it's double the pleasure, and
16
00:00:47.640 --> 00:00:50.359
they are both a living testament to the fact that
17
00:00:50.679 --> 00:00:53.799
you don't need to work at Google or at Meta
18
00:00:53.960 --> 00:00:56.359
or at some other fang in order to make a
19
00:00:56.479 --> 00:01:01.119
huge impact on web development. So we have Ryan Carneato
20
00:01:01.719 --> 00:01:05.040
and we have Tanner Lindsley. Hi, guys, want to introduce
21
00:01:05.079 --> 00:01:08.359
yourselves in case somebody somehow doesn't know who you.
22
00:01:08.319 --> 00:01:12.560
Are Oh sorry, I hit the plauser. Okay, I got
23
00:01:12.599 --> 00:01:15.319
to get that crowd to control themselves. Lots of fun.
24
00:01:15.760 --> 00:01:20.200
Yeah, I'm Brian Carneado, probably most known for creating solid
25
00:01:20.239 --> 00:01:24.400
Jazz and my work on Signals CEO of Signals and Tanner.
26
00:01:25.079 --> 00:01:26.400
I'm the tan Stack guy.
27
00:01:26.680 --> 00:01:29.480
And for those who don't happen to know, Tanstack is
28
00:01:29.560 --> 00:01:32.519
also where react query came from.
29
00:01:32.560 --> 00:01:37.280
Now tanstack query right, React Query I even I still
30
00:01:37.319 --> 00:01:38.760
call it that, which is fine.
31
00:01:38.840 --> 00:01:42.879
And also lots of other great tools. You've recently introduced
32
00:01:42.879 --> 00:01:43.319
a couple.
33
00:01:43.519 --> 00:01:48.560
Yeah, we we have just a couple. We're working on
34
00:01:48.599 --> 00:01:52.879
a new framework inspired by solid Start called tan sax Start.
35
00:01:53.920 --> 00:01:57.959
We have a router. We have a new library called pacer,
36
00:01:58.120 --> 00:02:03.599
which is about like debound throttling, ate leming stuff. We
37
00:02:03.640 --> 00:02:09.719
have the controversial name tan stack dB, which is a
38
00:02:09.800 --> 00:02:13.840
reactive client store. I mean it's a database, but it's
39
00:02:13.879 --> 00:02:15.639
only for like the client on the front end. It's
40
00:02:15.639 --> 00:02:20.520
pretty sweet, guys, except that it isn't right. Yeah, it's
41
00:02:21.319 --> 00:02:24.319
it's an awesome library. That's all you need to know. Uh.
42
00:02:25.080 --> 00:02:28.879
And we've got like table and form as well virtual
43
00:02:29.879 --> 00:02:33.120
h We've got a couple. We're even working on something
44
00:02:33.159 --> 00:02:36.319
called tan Sak dev tools right now, which is oh
45
00:02:36.400 --> 00:02:37.520
yeah about that.
46
00:02:37.599 --> 00:02:39.879
We will have to bring either you or somebody else
47
00:02:39.919 --> 00:02:41.960
on the team on to talk about that when you're
48
00:02:41.960 --> 00:02:44.759
different than you guys already h and I have to
49
00:02:44.800 --> 00:02:51.520
also mention create tense ten stack start or whatever Jack
50
00:02:52.479 --> 00:02:53.199
these days.
51
00:02:53.280 --> 00:02:55.800
Whatever we're going gonna call it, and it might even
52
00:02:55.840 --> 00:02:58.919
just be called create tan Stacking like that.
53
00:02:58.840 --> 00:03:01.159
For those of you don't know that is. We actually
54
00:03:01.280 --> 00:03:03.680
had Jack Harrington on the show to talk about it.
55
00:03:03.680 --> 00:03:07.879
It's an awesome replacement for create react at least.
56
00:03:08.280 --> 00:03:10.159
Yeah, we have some fun plans for it.
57
00:03:10.280 --> 00:03:13.240
So it's Tanstack Ranger. I'm looking at a last.
58
00:03:13.560 --> 00:03:19.439
Ranger is kind of a throwback to my old open
59
00:03:19.439 --> 00:03:21.960
source days. It's it's I needed a library to do
60
00:03:22.159 --> 00:03:28.199
multi range inputs, so like sliders with multiple handles. I
61
00:03:28.639 --> 00:03:32.560
made a headless version of it. I called it Ranger,
62
00:03:33.560 --> 00:03:34.360
which is kind of fun.
63
00:03:34.639 --> 00:03:37.759
See I'm thinking like Park Ranger and uh, you know
64
00:03:37.840 --> 00:03:40.759
Jellystone Park and I remember that.
65
00:03:42.000 --> 00:03:47.599
Yeah, it's probably it's it's the most niche library that
66
00:03:47.639 --> 00:03:50.639
we have, which it's cool. I still use it every
67
00:03:50.639 --> 00:03:51.120
now and then.
68
00:03:51.879 --> 00:03:54.120
And one more thing about you, Tanner, correct me if
69
00:03:54.159 --> 00:03:58.080
I'm wrong, but you're now you've transitioned to work full
70
00:03:58.159 --> 00:04:00.159
time on your open source staf.
71
00:04:00.319 --> 00:04:02.879
Right, yeah, about a year and a half ago.
72
00:04:03.039 --> 00:04:08.039
That is awesome. So basically you're the guy not making
73
00:04:08.039 --> 00:04:09.800
a living, so the rest of us can.
74
00:04:10.039 --> 00:04:15.719
I mean as of nine months ago, I'm making a
75
00:04:15.759 --> 00:04:16.439
good living now.
76
00:04:17.079 --> 00:04:19.399
So yeah, so what is your business model for that?
77
00:04:19.439 --> 00:04:25.480
Then? Well, it's it's different than most others, I think,
78
00:04:25.519 --> 00:04:31.680
so I abhor VC around oss. I've done venture capital
79
00:04:31.720 --> 00:04:37.040
for my last company, and I've also bootstrapped plenty of things.
80
00:04:37.839 --> 00:04:39.600
I didn't want to do that for tanse Dec. So
81
00:04:40.240 --> 00:04:45.199
Tensex basically run like a media company right now, as
82
00:04:45.240 --> 00:04:51.040
like a business side of things, so marketing, advertising, partnership,
83
00:04:51.160 --> 00:04:55.439
brand deals and the like. And that's how tanse Dec
84
00:04:56.000 --> 00:05:01.720
is making money and paying both me and also now
85
00:05:01.800 --> 00:05:05.600
contributing a lot towards contributors as well, and that's just
86
00:05:05.600 --> 00:05:07.959
going to grow over time hopefully.
87
00:05:08.000 --> 00:05:12.319
Does that mean running ads within your website, within your
88
00:05:13.040 --> 00:05:14.680
products or something else?
89
00:05:15.360 --> 00:05:18.759
Yeah, So tan stack dot com is the revenue generator
90
00:05:19.480 --> 00:05:25.160
and the libraries are just guests on the tan stack
91
00:05:25.199 --> 00:05:28.879
dot com show every day.
92
00:05:28.519 --> 00:05:32.279
That's interesting. Yeah, I'm really happy that it's working for you.
93
00:05:33.000 --> 00:05:36.439
Yeah, it's working so far, so we'll we'll see. I
94
00:05:36.439 --> 00:05:40.839
don't know if it's scalable or not, but it works
95
00:05:40.879 --> 00:05:43.240
for me, and I think that's that's good enough for now.
96
00:05:43.319 --> 00:05:46.680
And how about you, Ryan, how are things with you?
97
00:05:46.720 --> 00:05:47.160
Pretty good?
98
00:05:47.839 --> 00:05:52.279
I've been at Century now for almost a year, so okay, Yeah,
99
00:05:52.399 --> 00:05:54.959
like this week coming up marks a year Century So
100
00:05:55.800 --> 00:06:00.360
they've been great, been able to obviously support my U,
101
00:06:00.879 --> 00:06:02.240
R and D. I've been doing a lot this year
102
00:06:02.240 --> 00:06:05.759
because I've been working a lot of new areas kind
103
00:06:05.800 --> 00:06:10.720
of for upcoming releases of Solid and and they've been
104
00:06:10.720 --> 00:06:12.879
supporting lots of other ways. I've been getting closer with
105
00:06:12.920 --> 00:06:14.319
the syntax FM guys.
106
00:06:15.160 --> 00:06:16.600
I was gonna ask if you worked with them.
107
00:06:17.079 --> 00:06:20.040
Yeah, So we've been talking about how to up my
108
00:06:20.079 --> 00:06:24.199
game on video content and different kinds of media stuff
109
00:06:24.319 --> 00:06:25.399
like better promotion.
110
00:06:25.759 --> 00:06:28.720
So I'm guessing they told you you need to make
111
00:06:28.759 --> 00:06:29.879
longer videos.
112
00:06:30.480 --> 00:06:33.759
Yeah, that's funny, No, they were.
113
00:06:34.120 --> 00:06:36.199
Everyone's been really stoked on those shorter videos that I've
114
00:06:36.199 --> 00:06:38.399
been doing recently. They said they were like a little crunched,
115
00:06:38.800 --> 00:06:42.560
could do some more production value, but generally speaking, I
116
00:06:42.639 --> 00:06:46.439
usually stream for like five hours ish you know, maybe
117
00:06:46.439 --> 00:06:49.920
every other Friday or so. And I started in the
118
00:06:49.959 --> 00:06:53.120
last couple of months doing like ten minute videos, and
119
00:06:53.639 --> 00:06:55.319
for me, doing ten minute videos very hard.
120
00:06:55.319 --> 00:06:56.079
It's condensed.
121
00:06:56.120 --> 00:07:00.959
It's like because I picked really deep topics, but I
122
00:07:01.040 --> 00:07:03.079
just needed a place to point people too. When people
123
00:07:03.079 --> 00:07:05.600
are like, you know, signals, blah blah blah blah blah,
124
00:07:05.600 --> 00:07:07.360
you know, like complains. You know, I'm a React developer.
125
00:07:07.399 --> 00:07:09.120
I don't get why they important. It's just like, okay, well,
126
00:07:09.199 --> 00:07:11.759
can I make an FAQ basically as a video. And
127
00:07:12.199 --> 00:07:15.120
that's sort of what I've been trying to do. Find
128
00:07:15.160 --> 00:07:18.079
content that's sure enough that people will not like bulk
129
00:07:18.319 --> 00:07:22.360
looking at the whole length of the video, but then
130
00:07:22.439 --> 00:07:26.600
still get a lot of unique content in there. It's
131
00:07:26.639 --> 00:07:29.879
difficult because my expertise is I said, very very deep.
132
00:07:30.720 --> 00:07:33.759
You don't really find content like I do in most
133
00:07:34.040 --> 00:07:36.240
video content. Like you guys sometimes get really deep on
134
00:07:36.279 --> 00:07:38.519
your podcast, which is why I love this podcast. But
135
00:07:38.600 --> 00:07:42.079
a lot of video content isn't the same sort of thing.
136
00:07:42.319 --> 00:07:44.199
You know, it's either like how do you do this?
137
00:07:45.000 --> 00:07:49.720
Or it's like the most beginner intro level of stuff.
138
00:07:49.759 --> 00:07:52.759
So being able to ask the whys, I think is
139
00:07:52.800 --> 00:07:55.120
really really important and like looking at the design stuff.
140
00:07:55.160 --> 00:07:57.480
So I'm going to try and bridge that gap, you know,
141
00:07:57.519 --> 00:08:00.920
maybe pick smaller topics that I can actually talk about,
142
00:08:00.959 --> 00:08:02.879
you know, in seven to ten minutes.
143
00:08:03.439 --> 00:08:06.160
So you kind of remind me of that. I think
144
00:08:06.199 --> 00:08:08.759
it's Mark Twain who said I didn't have the time
145
00:08:08.800 --> 00:08:11.800
to write your long letters short letters, so I wrote
146
00:08:11.839 --> 00:08:15.199
you a long one. So yeah, it's exactly much much
147
00:08:15.199 --> 00:08:19.800
more challenging to create short and concise and to the
148
00:08:19.879 --> 00:08:20.759
point content.
149
00:08:21.319 --> 00:08:23.959
Yeah, especially if you spend all your time like like
150
00:08:24.199 --> 00:08:27.759
really like like just kind of exploring ideas and stuff,
151
00:08:27.800 --> 00:08:30.279
you know, and taking stuff which way to actually come
152
00:08:30.360 --> 00:08:32.879
up to a consolidated messages way more work. I can
153
00:08:32.879 --> 00:08:35.120
stream for five hours, but then I'm like mostly done.
154
00:08:36.080 --> 00:08:38.080
The video is going to take me at least two
155
00:08:38.200 --> 00:08:40.000
or three days.
156
00:08:39.720 --> 00:08:43.559
You know, that's for sure. Well, let's put it this way.
157
00:08:43.600 --> 00:08:45.519
I think that once you get the hang of it,
158
00:08:45.679 --> 00:08:48.759
you'll be able to do it much more effectively. Maybe
159
00:08:48.759 --> 00:08:50.840
you should also consult about it with THEO.
160
00:08:51.320 --> 00:08:51.519
Yeah.
161
00:08:51.600 --> 00:08:56.279
Yeah, he's been waiting for me to like level up that.
162
00:08:56.559 --> 00:08:58.200
He was like, yeah, I just keep on doing what
163
00:08:58.240 --> 00:08:59.960
you're doing, but when it's time come see me you know,
164
00:09:00.240 --> 00:09:02.799
like better gear, better stuff, you know.
165
00:09:03.080 --> 00:09:06.399
So yeah, yeah, I did one video for for you
166
00:09:06.639 --> 00:09:11.759
Mastery a couple of years ago, And the amount of
167
00:09:11.799 --> 00:09:14.399
work it takes to get to just to put together
168
00:09:15.159 --> 00:09:18.519
simple videos is crazy. Whether it's recording, I would assume
169
00:09:18.519 --> 00:09:20.879
that once you get your setup in place, you know,
170
00:09:20.960 --> 00:09:23.799
your your software and your different artwork components and your
171
00:09:23.840 --> 00:09:25.519
speakers and all that stuff, and you know what you're doing,
172
00:09:25.559 --> 00:09:29.000
it's probably a lot quicker. But that's that's got to
173
00:09:29.039 --> 00:09:31.120
be a learning curve just in getting set up to
174
00:09:31.159 --> 00:09:32.879
do video production like that.
175
00:09:33.440 --> 00:09:36.840
Yeah, and I like editing stuff in I'm a big
176
00:09:36.879 --> 00:09:39.960
fan of fireship videos and even my articles are like that.
177
00:09:40.000 --> 00:09:42.759
I've always done a lot of meme pictures and like
178
00:09:42.759 --> 00:09:45.879
like images to back up what I'm saying, Yes, can
179
00:09:45.919 --> 00:09:47.679
I keep it going? Even my conference talks are like
180
00:09:47.720 --> 00:09:50.320
that too. So I find the video editing actuallyising a
181
00:09:50.320 --> 00:09:52.039
long time because I need to find just the perfect
182
00:09:52.200 --> 00:09:57.000
clip or the perfect like image to kind of overlay
183
00:09:57.600 --> 00:10:01.000
the different parts. So like it's like it's almost on
184
00:10:01.039 --> 00:10:04.519
like a twenty second cadence, so like it's you know,
185
00:10:04.639 --> 00:10:05.679
twenty minute video.
186
00:10:05.960 --> 00:10:07.159
You know, that's a lot of clips.
187
00:10:07.600 --> 00:10:09.399
Well, just let AI do it for you.
188
00:10:10.240 --> 00:10:11.799
Well, you know, I have the same struggle with always
189
00:10:11.840 --> 00:10:14.120
trying to find a perfect dad joke to publish on
190
00:10:14.159 --> 00:10:15.960
a daily basis and to throw in here and there
191
00:10:16.000 --> 00:10:18.279
so I can somewhat they all perfect.
192
00:10:18.279 --> 00:10:19.639
Stage, they're all perfect.
193
00:10:20.120 --> 00:10:21.840
Oh boy, I got to tell you some stories about
194
00:10:21.840 --> 00:10:24.919
how they're not always, but that's a topic for another time.
195
00:10:25.200 --> 00:10:28.039
Yeah, I think we need to finally get to the
196
00:10:28.320 --> 00:10:30.919
to the crux to the main issue.
197
00:10:31.080 --> 00:10:33.080
We had a topic for today, any topic that we're
198
00:10:33.120 --> 00:10:34.639
here to discuss, gotcha.
199
00:10:34.720 --> 00:10:39.320
So again, I'll give a brief background. A while back,
200
00:10:39.399 --> 00:10:43.519
I had this idea of le let's go even further back.
201
00:10:43.639 --> 00:10:49.000
I started noticing a certain pattern that was occurring in
202
00:10:49.080 --> 00:10:53.440
a lot of frameworks, especially as they were becoming meta frameworks,
203
00:10:53.840 --> 00:10:56.480
and that's kind of and I termed it to come
204
00:10:56.480 --> 00:10:59.919
back of RPC, and we'll talk about what RPC is
205
00:11:00.360 --> 00:11:04.799
and why it's making this comeback now. But when I
206
00:11:04.960 --> 00:11:07.559
noticed that, it occurred to me that this could be
207
00:11:07.559 --> 00:11:11.039
an interesting topic for a conference talk, which I created
208
00:11:11.080 --> 00:11:15.120
and already gave once at JS Heroes in Romania. But
209
00:11:15.200 --> 00:11:17.679
I reached out to a lot of my friends, people
210
00:11:17.799 --> 00:11:24.240
like Ryan, like Tanner, like Rich Harris and others, and
211
00:11:24.320 --> 00:11:28.720
started in Jack Harrington, whom we mentioned, and started talking
212
00:11:28.759 --> 00:11:33.080
with them about this whole thing, and I realized that
213
00:11:33.120 --> 00:11:36.840
a lot of them had very different viewpoints about what
214
00:11:36.879 --> 00:11:40.559
our PC is, how it should or should not be used,
215
00:11:41.159 --> 00:11:46.559
why it's interesting or maybe not. And what this ended
216
00:11:46.679 --> 00:11:50.799
up is this conversation here. I basically asked both Ryan
217
00:11:50.879 --> 00:11:53.519
and Tanner if they'd like to come on the show
218
00:11:53.960 --> 00:11:57.639
and talk about this, so, you know, take it away, guys.
219
00:11:57.919 --> 00:12:02.440
Yeah, I start because I feel like this starts with
220
00:12:03.240 --> 00:12:06.759
stuff that I was doing. But to be fair, this
221
00:12:06.799 --> 00:12:08.879
is stuff that Tenor definitely relates to right off the bat,
222
00:12:08.919 --> 00:12:11.360
because the first thing you hit when you're writing a
223
00:12:11.360 --> 00:12:14.759
meta framework, like the most obvious thing is actually meta
224
00:12:14.759 --> 00:12:18.759
frameworks are centered around routing, right and the router And
225
00:12:19.679 --> 00:12:21.360
I know this has nothing to do with RPC right
226
00:12:21.399 --> 00:12:22.320
off the bat, but like.
227
00:12:23.000 --> 00:12:26.279
Maybe we should define our PC before we dive into it.
228
00:12:26.559 --> 00:12:31.879
Yeah, okay, sure, A remote procedure call basically this idea
229
00:12:31.879 --> 00:12:34.639
that you can in different environments call a function from
230
00:12:34.679 --> 00:12:35.559
the other environment.
231
00:12:36.039 --> 00:12:38.320
Because I thought it was really popular comedy for a moment,
232
00:12:38.399 --> 00:12:38.960
glad read.
233
00:12:40.519 --> 00:12:44.240
I like to use a slightly different definition the way
234
00:12:44.240 --> 00:12:49.600
that I like to define it is basically as a
235
00:12:49.639 --> 00:12:55.120
method for invoking a service or obtaining data from another process,
236
00:12:55.559 --> 00:12:59.679
even on another computer across the network, using a function
237
00:12:59.799 --> 00:13:04.679
call paradigm. Are you okay with this definition? Yes, So
238
00:13:04.720 --> 00:13:07.440
it's basically it looks like a function call. It feels
239
00:13:07.519 --> 00:13:10.600
like a function call. You. It's as easy to use
240
00:13:10.639 --> 00:13:13.360
as a natural to use as a function call, but
241
00:13:13.600 --> 00:13:17.320
instead of just actually being a function call, it translates
242
00:13:17.360 --> 00:13:18.960
to an operation across the net.
243
00:13:19.120 --> 00:13:19.360
Yeah.
244
00:13:19.799 --> 00:13:22.039
The funniest thing is, like my first introduction to rpcs
245
00:13:22.080 --> 00:13:24.759
didn't feel as easy or natural to use as function calls.
246
00:13:25.200 --> 00:13:26.360
I was using a.
247
00:13:26.519 --> 00:13:31.799
Like soap in Microsoft stuff back in the early two thousands,
248
00:13:31.879 --> 00:13:34.840
And if anyone's us that it's like all XML based
249
00:13:34.919 --> 00:13:38.960
and they call they get categorized under RPC. But that
250
00:13:39.080 --> 00:13:42.679
like in my head when someone says RPC to me, traditionally,
251
00:13:42.720 --> 00:13:44.600
that's what I thought of. I thought of these like
252
00:13:45.120 --> 00:13:49.960
XML end points from like Microsoft Server from like two
253
00:13:50.039 --> 00:13:52.799
thousand and two.
254
00:13:52.879 --> 00:13:53.399
Memories.
255
00:13:53.720 --> 00:13:56.159
Yeah, I'm a bit of a history buff. I'm a
256
00:13:56.159 --> 00:14:00.440
bit of a history buff. So it's interesting because it
257
00:14:00.600 --> 00:14:04.159
was that period in time where RPC was effectively dying
258
00:14:04.840 --> 00:14:07.960
so our PC was really RPC. The term was coined
259
00:14:08.000 --> 00:14:11.960
in the eighties. It became really popular in the nineties
260
00:14:12.120 --> 00:14:17.720
with the native platforms for it like Corba or Dcom
261
00:14:18.080 --> 00:14:22.399
from Microsoft, and then the Web happened, which kind of
262
00:14:22.519 --> 00:14:27.039
killed it. Soap was an attempt to somehow continue to
263
00:14:27.120 --> 00:14:30.879
do RPC despite the Web, and we can talk about
264
00:14:30.919 --> 00:14:33.559
why the web killed RPC for a while at least,
265
00:14:34.279 --> 00:14:37.240
and now it's making a comeback in a much more
266
00:14:37.360 --> 00:14:40.600
natural way, which is in a lot of ways very
267
00:14:40.639 --> 00:14:45.159
reminiscent of how it was in the nineties, but compatible
268
00:14:45.279 --> 00:14:48.200
with the modern technologies that we use nowadays.
269
00:14:48.440 --> 00:14:51.600
Right, Yeah, yeah, I mean that sounds about right, Like
270
00:14:51.679 --> 00:14:55.039
no one was touching RPC after that early mid two
271
00:14:55.080 --> 00:14:58.840
thousands period until maybe like twenty twenty.
272
00:14:58.919 --> 00:15:03.720
Is they're like in the web technology, But.
273
00:15:03.960 --> 00:15:09.039
I mean yes, obviously, when we start designing these surver
274
00:15:09.080 --> 00:15:14.080
rendered meta frameworks where we actually have the server and
275
00:15:14.120 --> 00:15:18.240
the client being developed in the same place, you start
276
00:15:18.360 --> 00:15:21.080
going like, well, if I control both sides, why not
277
00:15:21.159 --> 00:15:22.600
like make that pipe easier.
278
00:15:23.039 --> 00:15:24.840
But I mean that was the motivation.
279
00:15:24.960 --> 00:15:28.080
The thing for me personally when I started looking at
280
00:15:28.080 --> 00:15:31.039
this stuff was I wasn't I was aware of this
281
00:15:31.159 --> 00:15:34.039
the soap stuff you know and that, But I was
282
00:15:34.080 --> 00:15:36.679
just trying to like I was looking at other meta frameworks,
283
00:15:36.840 --> 00:15:38.759
was this is the beginning of all start Like twenty
284
00:15:38.799 --> 00:15:41.159
twenty one is actually before I even really sold at
285
00:15:41.200 --> 00:15:42.799
one point zero, And I was like looking at other
286
00:15:42.840 --> 00:15:45.879
meta frameworks a bit, and I was looking like next
287
00:15:45.960 --> 00:15:50.879
JS and and mostly and like you know sapper from
288
00:15:51.200 --> 00:15:55.720
and like next and they all had these like API
289
00:15:55.919 --> 00:15:58.000
end points, like like where you'd like do this file
290
00:15:58.279 --> 00:16:03.639
based routing system with apien points. And the thing that
291
00:16:03.679 --> 00:16:04.919
was weird for me is I used to be a
292
00:16:05.000 --> 00:16:07.759
real guy for a bit, so like you would define
293
00:16:07.799 --> 00:16:11.360
like like in the file system, you'd define I guess
294
00:16:11.360 --> 00:16:13.120
not a file system was an auto madeive.
295
00:16:12.879 --> 00:16:13.639
Filesism, but whatever.
296
00:16:13.679 --> 00:16:17.519
You you skelton out these like models essentially and API
297
00:16:17.600 --> 00:16:20.279
n points and they would describe the whole collection of
298
00:16:20.320 --> 00:16:24.080
the whole model of things, and the filesystem approached a
299
00:16:24.080 --> 00:16:26.600
lot of these APIs had taken was kind of it
300
00:16:26.600 --> 00:16:30.120
felt weird to me because you'd have like a different
301
00:16:30.159 --> 00:16:35.120
file for like the general like groups versus like group
302
00:16:35.159 --> 00:16:37.279
I D like you didn't put all the crowd commands
303
00:16:37.320 --> 00:16:41.120
together like it would like separate based on the URL path,
304
00:16:41.200 --> 00:16:45.039
not based on the conceptual model, if that makes any sense,
305
00:16:45.039 --> 00:16:47.480
Like instead of being talking about groups as a single thing,
306
00:16:47.600 --> 00:16:50.559
you would have like groups and groups slash.
307
00:16:50.600 --> 00:16:52.639
I d like it's a funny thing.
308
00:16:53.000 --> 00:16:54.960
But I was looking at these API shapes and I
309
00:16:55.000 --> 00:16:56.799
was like, this is such a hassle to like every
310
00:16:56.840 --> 00:16:59.080
time I do this to build out these files.
311
00:17:01.600 --> 00:17:03.919
I saw Remix. I think this was for me.
312
00:17:04.680 --> 00:17:07.680
They did their big reveal in spring twenty twenty one,
313
00:17:07.720 --> 00:17:10.960
and I know this, and when I saw their loaders
314
00:17:11.039 --> 00:17:13.079
and actions and the way that they doubled it up
315
00:17:13.079 --> 00:17:15.200
on the API side, I'm like, this is kind of nice.
316
00:17:15.559 --> 00:17:19.599
It's like turned into a single approach, because what was
317
00:17:19.680 --> 00:17:22.039
kind of awkward was that people would build their app
318
00:17:22.039 --> 00:17:23.960
in one folder and then they'd build their API and
319
00:17:24.000 --> 00:17:26.200
another folder, and it was getting kind of clunky. You
320
00:17:26.359 --> 00:17:28.839
do everything twice, kind of connecting it up. And they
321
00:17:28.920 --> 00:17:30.480
were like, no, you can just kind of stick it
322
00:17:30.519 --> 00:17:32.799
all in the same place, follow the same kind of pattern.
323
00:17:33.440 --> 00:17:35.799
The challenge I had Remix is because I've been working
324
00:17:35.799 --> 00:17:39.880
on routing for a while and nested routing and with
325
00:17:40.000 --> 00:17:43.279
you know, parallel data fetching and all these things. Is
326
00:17:43.680 --> 00:17:47.519
the remix loader basically said that this part of the
327
00:17:47.599 --> 00:17:51.880
UL loads this data, and that wasn't granular enough for me.
328
00:17:51.960 --> 00:17:54.039
I was working a solid gazz which is based on singles.
329
00:17:54.039 --> 00:17:57.519
So as you can imagine, there's multiple different data sources.
330
00:17:57.519 --> 00:17:59.839
You want them to update independently, right, you want to
331
00:17:59.839 --> 00:18:03.039
be to refresh them independently. You only want to update
332
00:18:03.079 --> 00:18:05.279
certain parts of the page. Treating the whole page like
333
00:18:05.319 --> 00:18:09.680
it was like a single data flow was not particularly
334
00:18:10.279 --> 00:18:12.920
nice for me. So I was like, okay, can I
335
00:18:12.960 --> 00:18:16.759
take my kind of like route loaders, which are they're
336
00:18:16.799 --> 00:18:19.319
not really loaders, they're isomorphic. They run on both sides,
337
00:18:19.680 --> 00:18:23.440
these kind of nested rout kind of areas where you
338
00:18:23.440 --> 00:18:26.359
can fetch data and instead of you know, hitting API
339
00:18:26.440 --> 00:18:28.759
calls like we used to, instead of using one single loader,
340
00:18:28.960 --> 00:18:32.480
can we make it more ergonomic to define individual pieces
341
00:18:32.480 --> 00:18:35.759
of data you can fetch. And I was looking when
342
00:18:35.759 --> 00:18:37.200
I was doing the client side, and I'm like, I
343
00:18:37.240 --> 00:18:39.920
love this. You know I can put you know, you know,
344
00:18:40.119 --> 00:18:42.079
solid query. This is like a ten I rack in
345
00:18:42.119 --> 00:18:44.079
the conversation for a second, but like I can put
346
00:18:44.279 --> 00:18:47.519
like my different data fetching things inside this loading and
347
00:18:47.559 --> 00:18:49.799
I can manage them separately. If I'm on this page,
348
00:18:49.880 --> 00:18:53.000
can I can grab users and their posts and have
349
00:18:53.079 --> 00:18:57.519
multiple things and call them and invalidate them separately. And
350
00:18:57.559 --> 00:19:00.160
I'm like, this is a great pattern. It works on
351
00:19:00.160 --> 00:19:03.200
the server, works on the client. The only problem is
352
00:19:03.400 --> 00:19:06.240
you have to call these extra API in points. So
353
00:19:07.079 --> 00:19:10.319
I started working on a solution, which was, what if
354
00:19:10.359 --> 00:19:13.079
I could use the file system in a nicer way,
355
00:19:13.200 --> 00:19:15.599
like better than the API in points, where instead of
356
00:19:15.799 --> 00:19:18.400
being quite as bulky and like having these URLs, I
357
00:19:18.400 --> 00:19:21.240
could use like a proxy or something like where you
358
00:19:21.279 --> 00:19:24.359
could maybe make some types for an object, and based
359
00:19:24.400 --> 00:19:26.519
on what path you go through the object, it would
360
00:19:26.559 --> 00:19:28.960
construct the URL on the client and then know what
361
00:19:29.079 --> 00:19:32.039
endpoint to hit on the server. And I kind of
362
00:19:32.079 --> 00:19:35.200
put this together and I call them actions after remixes actions.
363
00:19:35.240 --> 00:19:39.079
And the difference is they weren't really exactly actions, or
364
00:19:39.119 --> 00:19:41.000
they were both actions and loaders. You could basically hit
365
00:19:41.000 --> 00:19:43.640
these URLs both on data fetching and on mutation, and
366
00:19:43.680 --> 00:19:47.559
you could call them They're just like autogeneratid APIs. And
367
00:19:48.119 --> 00:19:50.799
I remember I put that out around April. I made
368
00:19:50.839 --> 00:19:53.759
some demos around April twenty twenty one, but then Solid
369
00:19:53.799 --> 00:19:55.279
one point zero needed to get released, and I put
370
00:19:55.279 --> 00:19:59.559
it aside, and I basically was like showing people and
371
00:19:59.799 --> 00:20:01.920
talk like how cool this was going to be, but
372
00:20:02.319 --> 00:20:04.240
you know, people just like, oh, yeah, yeah, whatever, Ryan,
373
00:20:04.440 --> 00:20:07.720
and and then and then it was almost a year later.
374
00:20:08.200 --> 00:20:10.759
It could be fair half of us don't know, don't
375
00:20:11.400 --> 00:20:13.680
often don't understand what you're talking about, so.
376
00:20:13.640 --> 00:20:17.079
That that's that's perfectly fair. But some people did.
377
00:20:17.119 --> 00:20:20.480
And I was talking to someone in December or like
378
00:20:20.480 --> 00:20:22.680
around Christmas time, and they're like, oh, isn't that what
379
00:20:22.720 --> 00:20:26.920
blitz JS is. I'm like, Blitz, isn't that next JSS thing?
380
00:20:27.400 --> 00:20:29.440
And I look at it, and sure enough, that is
381
00:20:29.559 --> 00:20:33.400
actually what blitz was. I basically independently also came up
382
00:20:33.440 --> 00:20:34.960
something similar to what Blitz was.
383
00:20:34.920 --> 00:20:37.440
Which is blitz what is it?
384
00:20:37.440 --> 00:20:37.720
It was?
385
00:20:37.799 --> 00:20:40.799
It was it was kind of like a meta framework
386
00:20:40.839 --> 00:20:43.960
on top of Next. I thought it was like Redwood,
387
00:20:44.039 --> 00:20:46.119
like it was one of those more opinionated meta frameworks
388
00:20:46.160 --> 00:20:49.200
on top of Next. But eventually they just became like
389
00:20:49.240 --> 00:20:53.079
a Next plug in and kind of downscaled it because
390
00:20:53.119 --> 00:20:54.799
but originally it was like a separate product, like you
391
00:20:54.880 --> 00:20:58.839
when installed Next, you install Blitz, and it was it
392
00:20:58.880 --> 00:21:02.200
was a React meta frame essentially. But it's cool feature
393
00:21:02.319 --> 00:21:06.759
was that it had these basically kind of generated API
394
00:21:07.039 --> 00:21:09.839
functions in the same kind of way that I was describing,
395
00:21:10.799 --> 00:21:16.279
where you could just kind of put these basically API
396
00:21:16.359 --> 00:21:18.720
call things in a file folder structure and then call
397
00:21:18.759 --> 00:21:21.519
them directly without like the fetch and the ceremony around
398
00:21:21.559 --> 00:21:23.720
like that. You could just call them basically it's functions
399
00:21:23.839 --> 00:21:26.880
via like a proxy like I was talking about, because
400
00:21:27.359 --> 00:21:30.279
the cool thing that the proxy approaches you can have
401
00:21:30.279 --> 00:21:32.519
the proxy return whatever you want, so it just wraps
402
00:21:32.559 --> 00:21:35.720
the details of the fetch away from you. So it
403
00:21:35.799 --> 00:21:37.799
is kind of the beginning of this RPC thing because
404
00:21:37.799 --> 00:21:40.160
you still have the API point where you have a
405
00:21:40.160 --> 00:21:43.559
file system running telling you like basically where these functions are.
406
00:21:43.640 --> 00:21:45.559
But then you could use the path on the proxy
407
00:21:45.680 --> 00:21:49.559
like get users dot get or like whatever to actually
408
00:21:49.559 --> 00:21:53.359
construct the URL and obscure the fetching. And I know
409
00:21:53.400 --> 00:21:55.680
this is kind of crazy history, but you know, like
410
00:21:56.000 --> 00:21:57.799
beyond where we ended up, but it was important for
411
00:21:57.839 --> 00:21:59.039
me to get there because when I went back to
412
00:21:59.039 --> 00:22:01.480
solid Start and after playing with this again, by this
413
00:22:01.559 --> 00:22:04.559
time I had met Nikhil Sarah, who was kind of
414
00:22:04.799 --> 00:22:08.880
responsible for a lot of stuff in solid ecosystem. He
415
00:22:09.119 --> 00:22:11.240
did a lot of the heavy lifting on the original
416
00:22:11.240 --> 00:22:15.519
salt Start release, and he also created Vinci, which we
417
00:22:15.680 --> 00:22:18.160
used to actually base salts Start and tasks Start initially.
418
00:22:18.519 --> 00:22:21.599
And he was like, man, veat is amazing. We don't
419
00:22:21.599 --> 00:22:23.640
need to use all this proxy stuff. We can just
420
00:22:23.839 --> 00:22:27.480
use a compiler and split these things out, like even
421
00:22:27.519 --> 00:22:29.559
in the middle of the files, like it doesn't matter.
422
00:22:29.559 --> 00:22:32.440
He started doing crazy stuff where he was analyzing like
423
00:22:33.400 --> 00:22:36.279
things further down the tree and hoisting them automatically and
424
00:22:36.279 --> 00:22:38.799
doing like all this stuff. And I'm like, this is crazy.
425
00:22:38.880 --> 00:22:43.240
I can't even wrap my head around what's happening. But
426
00:22:43.519 --> 00:22:45.240
he's like, look, as long as we have a symbol,
427
00:22:45.400 --> 00:22:47.079
like some way of it's saying like this is a
428
00:22:47.839 --> 00:22:50.240
is a function call, we don't need to use the
429
00:22:50.240 --> 00:22:52.279
file system. We can just go like this is a
430
00:22:52.359 --> 00:22:55.799
server function or whatever, and we passed the function to it,
431
00:22:56.119 --> 00:22:59.920
and now that function will always be called on the server.
432
00:23:00.759 --> 00:23:03.240
This is where you guys invented bling. I think you
433
00:23:03.359 --> 00:23:04.720
called it back then, right.
434
00:23:04.680 --> 00:23:06.680
Yes, almost.
435
00:23:06.799 --> 00:23:10.079
Bling would come very soon soon when we brought Tanner in.
436
00:23:10.119 --> 00:23:15.240
On Tanner, what this I actually presented our original version
437
00:23:15.519 --> 00:23:18.640
like this at vcomp the first b COMP back in
438
00:23:19.000 --> 00:23:22.279
September twenty twenty two, and that's when people were like, oh,
439
00:23:22.480 --> 00:23:24.119
this is actually kind of cool, you know, because it
440
00:23:24.200 --> 00:23:26.920
had types like when you start having functions and you
441
00:23:26.920 --> 00:23:28.839
can write them like functions where you can just import
442
00:23:28.880 --> 00:23:31.240
them the types match up.
443
00:23:32.000 --> 00:23:35.559
Yeah, And I'll get to that because it brings an
444
00:23:35.599 --> 00:23:40.440
interesting point from my perspective about why RPC is so
445
00:23:40.519 --> 00:23:44.880
attractive and what changed, because we talked about how the
446
00:23:44.920 --> 00:23:47.839
web kind of killed RPC, so it's interesting to talk
447
00:23:47.880 --> 00:23:51.039
about how RPC was able to make this kind of comeback.
448
00:23:51.319 --> 00:23:53.640
But before we go there, Tanner, I really want to
449
00:23:53.640 --> 00:23:55.519
bring you into the conversation finally.
450
00:23:56.079 --> 00:23:59.400
So I mean, it is basically almost at that point
451
00:23:59.440 --> 00:24:04.079
because Tanner is really into types. So after I demoed
452
00:24:04.119 --> 00:24:06.559
this stuff and the type stuff, what came out in
453
00:24:07.519 --> 00:24:09.279
the world that we realized that, like, what's cool, You
454
00:24:09.319 --> 00:24:11.400
can literally write the function as is. You don't you
455
00:24:11.440 --> 00:24:13.200
know a lot of type things that graft you or whatever.
456
00:24:13.200 --> 00:24:15.640
You'd have to write these schemas were this the types
457
00:24:15.880 --> 00:24:19.839
inherent off the functions simply from importing them automatical transferred.
458
00:24:19.880 --> 00:24:21.240
You didn't have to do anything you wouldn't be doing
459
00:24:21.319 --> 00:24:25.680
usually for typing. So once once we uh basically realized that,
460
00:24:27.000 --> 00:24:31.240
uh you know, uh, I started kind of publishing it
461
00:24:31.279 --> 00:24:34.720
out there and talking to other people. I was like, man,
462
00:24:35.279 --> 00:24:37.599
I still couldn't get over how magical it felt. And
463
00:24:37.640 --> 00:24:39.599
then I looked over it Quick and I was like,
464
00:24:40.000 --> 00:24:42.039
maybe we just need a better symbol. So I was like,
465
00:24:42.160 --> 00:24:44.720
let's add a dollar sign on it. And I actually
466
00:24:44.759 --> 00:24:46.720
told the Quick guys like they didn't know I did this,
467
00:24:46.759 --> 00:24:50.039
and I was like, I was tarting to manual In
468
00:24:50.519 --> 00:24:52.599
at a conference in that fall, and I was like, man,
469
00:24:53.119 --> 00:24:55.400
I think Quick could add this. I honestly stole your
470
00:24:55.400 --> 00:24:58.240
guys's dollar sign just because it's like a good indicator.
471
00:24:58.279 --> 00:25:00.279
And I'm like, we can just like you. It's just
472
00:25:00.319 --> 00:25:01.480
the reverse of what Quick does.
473
00:25:01.559 --> 00:25:03.559
Quick it was really good at pulling out these little
474
00:25:03.559 --> 00:25:06.279
pieces on the client. This is like pulling out these
475
00:25:06.279 --> 00:25:08.720
little pieces for the server. It's just like inverse Quick
476
00:25:08.759 --> 00:25:12.200
and they added it to their meta framework within a
477
00:25:12.200 --> 00:25:14.640
month after that conversation, like they were just like, yeah,
478
00:25:14.640 --> 00:25:17.279
we already have everything here, and they did it almost immediately.
479
00:25:17.519 --> 00:25:21.359
And as said, that's when tanner Gun involved around that point. Oh,
480
00:25:21.400 --> 00:25:23.440
actually it might have been even a little bit later,
481
00:25:23.640 --> 00:25:27.240
is around when next Uh and React they were like
482
00:25:27.640 --> 00:25:30.160
saw this stuff too, and they're like, oh, and they
483
00:25:30.200 --> 00:25:33.279
came up with like use server, but it was specific
484
00:25:33.279 --> 00:25:38.440
for their for their rpcs, for their server function communication.
485
00:25:38.039 --> 00:25:41.039
Their Initially they actually had it in the fine names
486
00:25:41.039 --> 00:25:44.880
if you recall the dot server dot ts and dot
487
00:25:44.920 --> 00:25:45.839
client dot t s.
488
00:25:46.319 --> 00:25:48.480
That was that was the catalyst for me right there.
489
00:25:48.640 --> 00:25:50.359
Yeah, I mean there there was there was like a
490
00:25:50.400 --> 00:25:56.920
subtle different like put it because technically server functions start
491
00:25:56.960 --> 00:26:00.240
on the server and there's like a naming convention where
492
00:26:00.240 --> 00:26:02.079
they're like, okay, these are server, these are client, and
493
00:26:02.119 --> 00:26:06.279
these are shared. But then like it's a different scenario
494
00:26:06.359 --> 00:26:08.599
because the server stuff can be done all in a
495
00:26:08.640 --> 00:26:11.759
single pass, like in a single go. They when they
496
00:26:11.799 --> 00:26:14.680
originally came up with that, that was to denote server functions,
497
00:26:14.720 --> 00:26:19.599
but not sorry, server components, not necessarily server functions, right or.
498
00:26:19.480 --> 00:26:24.440
Like they didn't have an aultation. Use client came as
499
00:26:24.480 --> 00:26:28.519
an alternative to dot server and dot client my fine names.
500
00:26:28.799 --> 00:26:33.519
They didn't have anything for you server, which came around.
501
00:26:33.240 --> 00:26:36.680
Later, right exactly, So they started proposing this stuff and
502
00:26:37.000 --> 00:26:38.839
I mean, yeah, Tenner can jump in at this point,
503
00:26:38.880 --> 00:26:40.839
but I think he saw what they were doing and
504
00:26:40.839 --> 00:26:42.119
it was just like, what the hell is this?
505
00:26:43.799 --> 00:26:46.200
I didn't I mean, I thought it was neat. I
506
00:26:46.240 --> 00:26:49.240
was more interested in, like what they were doing under
507
00:26:49.240 --> 00:26:52.359
the hood with like the compilation, what was actually happening
508
00:26:52.440 --> 00:26:57.039
to the build and transforming that the AST and whatnot.
509
00:26:57.160 --> 00:27:03.720
But I did not really like the approach to like
510
00:27:04.599 --> 00:27:08.880
use client use server at least for like RPC. I
511
00:27:08.920 --> 00:27:13.240
looked at it and I was excited about like, oh,
512
00:27:13.359 --> 00:27:16.720
I can just throw this token in there and all
513
00:27:16.720 --> 00:27:19.599
of a sudden creat an RPC, and like that part's cool.
514
00:27:20.400 --> 00:27:23.839
But then all these questions started bubbling up about like, Okay,
515
00:27:24.640 --> 00:27:30.000
clearly they don't believe that like configuring and RPC is
516
00:27:30.039 --> 00:27:33.839
as simple as a one string Like that's ridiculous.
517
00:27:33.960 --> 00:27:36.720
So I want to touch that briefly again to give
518
00:27:37.240 --> 00:27:40.640
a little bit of context to our listeners. So we
519
00:27:40.720 --> 00:27:45.119
talked about the fact that RPC is about invoking a
520
00:27:45.240 --> 00:27:49.039
function somewhere else as if it's a local fun a
521
00:27:49.079 --> 00:27:54.359
local function, and specifically in the context of full stack frameworks,
522
00:27:54.720 --> 00:27:59.759
it's basically invoking a server side function from client side
523
00:27:59.759 --> 00:28:03.160
code using the function called paradigm. So it looks and
524
00:28:03.200 --> 00:28:05.640
feels like a function. Now, in order to be able
525
00:28:05.720 --> 00:28:08.720
to do that, you kind of need to have, from
526
00:28:08.759 --> 00:28:12.960
my perspective, three things. First of all, you need to
527
00:28:13.000 --> 00:28:17.359
have type safety. Otherwise what's the point and going back
528
00:28:17.400 --> 00:28:21.039
to your or to your point, Ryan ab when disappeared,
529
00:28:21.079 --> 00:28:25.279
Obviously it only came into being after Typescript really went mainstream,
530
00:28:25.400 --> 00:28:32.799
because before Typescript, the whole typing thing was irrelevant. And
531
00:28:33.240 --> 00:28:37.279
the other thing that you need is to be able
532
00:28:37.319 --> 00:28:41.400
to simulate blocking you call to the remote function. You
533
00:28:41.440 --> 00:28:45.240
want to have it to feel like a local function,
534
00:28:45.319 --> 00:28:49.720
which means you don't get the execution back until that
535
00:28:49.759 --> 00:28:53.640
remote function finishes and provides a value. And we only
536
00:28:53.680 --> 00:28:55.640
got that after we got a sinkle weight.
537
00:28:56.240 --> 00:28:59.880
Basically, yeah, yeah, I mean, I'm native support of promise is,
538
00:29:00.039 --> 00:29:03.359
but more specific to this conversation, when framework started having
539
00:29:04.079 --> 00:29:05.839
tools to do what they think, which secularly you know.
540
00:29:06.160 --> 00:29:10.119
And which brings me back to the final point is ideally,
541
00:29:10.480 --> 00:29:14.599
not necessarily, but ideally you also want what you mentioned
542
00:29:14.640 --> 00:29:20.079
about vat, the ability to effectively instrument the code basically
543
00:29:20.279 --> 00:29:24.000
write something that looks like a function call, identify that
544
00:29:24.079 --> 00:29:25.920
this code is going to be running on the client,
545
00:29:26.240 --> 00:29:28.480
this code is going to be running on the server
546
00:29:28.880 --> 00:29:32.799
and generate all the magic code that makes this thing work. Basically,
547
00:29:32.839 --> 00:29:37.119
it's it's a stub and on the client and on
548
00:29:37.160 --> 00:29:41.920
the server that handles the whole networking layer underneath that
549
00:29:42.200 --> 00:29:42.960
function call.
550
00:29:43.559 --> 00:29:45.440
Now I'm mentioning that you don't.
551
00:29:45.359 --> 00:29:51.839
Necessarily have to have it because types trpc does without it,
552
00:29:52.559 --> 00:29:58.799
which makes it less magical and and also less fun. Potentially,
553
00:30:00.160 --> 00:30:03.599
going back to I want to give Tanner, I basically
554
00:30:03.640 --> 00:30:08.039
stole the mic from Tanner. So Tanner, you said that
555
00:30:08.319 --> 00:30:12.359
you looked at that the fact that they introduced this
556
00:30:12.480 --> 00:30:15.119
kind of magic string and all of a sudden it
557
00:30:15.319 --> 00:30:18.599
kind of worked, and you had thoughts about.
558
00:30:18.359 --> 00:30:27.160
That, Yeah, because like details matter eventually, details matter a lot.
559
00:30:27.480 --> 00:30:31.960
Like I think what you see is like you you
560
00:30:32.119 --> 00:30:37.079
write use server and a function, and that's that's really magical,
561
00:30:37.599 --> 00:30:40.400
and it's it's magical both in a sense of like
562
00:30:40.880 --> 00:30:44.039
it's doing a lot under the hood for you, but
563
00:30:44.119 --> 00:30:50.720
it's also a magical experience for most like basic operations
564
00:30:50.799 --> 00:30:55.400
or basic use cases. It's so simple, it's deceptively simple
565
00:30:55.519 --> 00:30:57.480
that it's like, oh, that's all it takes, right, and
566
00:30:57.519 --> 00:31:00.720
you just you put U server in there, But there's
567
00:31:00.799 --> 00:31:05.799
so many details that bubble up that you cannot get
568
00:31:05.799 --> 00:31:10.319
away from the fact that this is happening over the network.
569
00:31:10.759 --> 00:31:17.400
There are implementation details there that matter sometimes and there
570
00:31:17.559 --> 00:31:27.039
for example, yeah, caching protocol methods, header's authentication. There's there's
571
00:31:27.119 --> 00:31:31.839
like edge case flexibility that needs to be inherently in
572
00:31:31.880 --> 00:31:34.599
the system to allow you to do things that you
573
00:31:34.839 --> 00:31:38.079
maybe don't do ninety percent of the time, but you
574
00:31:38.119 --> 00:31:42.079
will need to do. One of the basic ones was
575
00:31:44.000 --> 00:31:48.640
you server defaults to a post sorry not be defaults.
576
00:31:48.680 --> 00:31:53.400
It is a post request in like next jays and
577
00:31:53.480 --> 00:31:56.359
React reacts to kind of spec right.
578
00:31:56.519 --> 00:31:59.279
You also don't have any control, like you said, either
579
00:31:59.359 --> 00:32:01.559
over the end point all the protocol.
580
00:32:01.440 --> 00:32:05.240
No or headers or anything like that. You're you can
581
00:32:05.839 --> 00:32:08.119
kind of get it some of the implementation, but only
582
00:32:08.200 --> 00:32:11.480
at like a global place. But if you wanted to
583
00:32:11.519 --> 00:32:14.559
customize any of that other stuff, you can't really do that,
584
00:32:14.759 --> 00:32:16.759
and you have to break out of the system entirely.
585
00:32:17.440 --> 00:32:21.119
And I didn't like that because immediately I was like, well,
586
00:32:21.160 --> 00:32:24.640
I want to use this with reac query, and that's
587
00:32:24.640 --> 00:32:27.720
great for cashing, But wouldn't it be great if if
588
00:32:27.759 --> 00:32:31.319
the browser could actually just cash this get request that
589
00:32:31.359 --> 00:32:35.119
I'm making, it's totally capable of doing that. And then
590
00:32:35.119 --> 00:32:39.160
there's questions of well, how is that URL formulated in
591
00:32:39.200 --> 00:32:42.039
a way that's going to be stable for the browser
592
00:32:42.039 --> 00:32:44.720
to cash, And there's lots of questions that came up
593
00:32:44.720 --> 00:32:47.640
for me around that, and I just knew at one
594
00:32:47.720 --> 00:32:51.480
point we're going to need to like ninety percent of
595
00:32:51.519 --> 00:32:54.920
the time same experience as just use server. Just create
596
00:32:54.960 --> 00:32:57.039
a function, give it some kind of a symbol, a
597
00:32:57.119 --> 00:33:00.759
dollar sign or something that would make it easy for
598
00:33:01.039 --> 00:33:04.200
a bulk of the use cases, and then have at
599
00:33:04.319 --> 00:33:08.880
least the ability or the option to expand and and
600
00:33:09.119 --> 00:33:13.599
make that configuration advanced. I just don't understand when people
601
00:33:13.680 --> 00:33:18.480
create APIs that cannot be ripped away easily or like
602
00:33:18.559 --> 00:33:22.119
dug into easily. I don't understand it. And these directives
603
00:33:22.160 --> 00:33:25.839
of use server or use cash or whatever are like
604
00:33:25.960 --> 00:33:28.160
the biggest offenders of that principle for me.
605
00:33:28.839 --> 00:33:34.000
So it's it's funny because as you get guys may
606
00:33:34.039 --> 00:33:36.680
not know actually I started with server functions, solid uses
607
00:33:36.759 --> 00:33:42.200
use server today because compatibility with react or like conceptually
608
00:33:42.480 --> 00:33:44.759
there yes, wrapper functions are.
609
00:33:45.559 --> 00:33:49.039
By the way, like intense sex start you can write
610
00:33:49.160 --> 00:33:52.200
use server ye and you'll get the same experience.
611
00:33:52.279 --> 00:33:56.519
But it's yeah, like rapper functions are as tenders that
612
00:33:56.559 --> 00:34:01.480
are almost necessary for configuration. And that's like positively at
613
00:34:01.519 --> 00:34:07.039
least is that because this configuration comes from the client,
614
00:34:07.359 --> 00:34:09.840
wrapping is definitely something you can do, Like you can
615
00:34:10.239 --> 00:34:13.280
compose these kind of pieces on top of server functions
616
00:34:13.320 --> 00:34:17.679
because the server parts on the server, the use server,
617
00:34:17.840 --> 00:34:21.800
the server offs and represents the split between the like
618
00:34:21.880 --> 00:34:23.440
this goes on server, this goes in the client.
619
00:34:23.559 --> 00:34:25.000
So it's basically.
620
00:34:26.880 --> 00:34:29.239
One of the things that kind of enabled I'll give
621
00:34:29.239 --> 00:34:31.840
you in a second just mentioning that one of the
622
00:34:31.880 --> 00:34:34.960
things that enabled this whole thing is like you mentioned
623
00:34:34.960 --> 00:34:38.760
when we talked about VAT, is that smart bundler that's
624
00:34:39.079 --> 00:34:42.519
that's analyzing the code in any event, sees it and
625
00:34:42.559 --> 00:34:45.519
then knows to generate different code for the server and
626
00:34:45.639 --> 00:34:48.440
different code for the client from the same source code. Right,
627
00:34:49.039 --> 00:34:50.360
That's the sweet magic.
628
00:34:50.800 --> 00:34:53.119
We should talk about beat here for a little bit more,
629
00:34:53.239 --> 00:34:57.519
because the thing is at this point Tenner and I
630
00:34:57.599 --> 00:35:00.679
are talking the keel and we're like every framework could
631
00:35:00.760 --> 00:35:00.920
use this.
632
00:35:00.960 --> 00:35:01.840
Why just use this.
633
00:35:01.800 --> 00:35:05.239
Only in solid Why have you know, you know, quick
634
00:35:05.320 --> 00:35:08.760
make their own version. Why have next make their own version?
635
00:35:10.000 --> 00:35:14.360
And Antenner was like, okay, let's let's like just make
636
00:35:14.400 --> 00:35:16.679
a generic plugin for this, right, So that's where Blain
637
00:35:16.800 --> 00:35:19.760
came about. When it was like Kennedy, he picked it
638
00:35:19.800 --> 00:35:22.440
up and he was like, let's let's make this generic.
639
00:35:22.480 --> 00:35:23.880
The thing that is.
640
00:35:23.840 --> 00:35:28.239
Bling didn't quite survive in the same form because what
641
00:35:28.280 --> 00:35:32.039
we realized was Blain was basically like a was it
642
00:35:32.079 --> 00:35:34.440
a Babel plug in. It was basically a transform. It
643
00:35:34.519 --> 00:35:41.559
basically transformed a code without bundler awareness, which does work
644
00:35:42.559 --> 00:35:45.159
a lot in this in the simple cases, but it
645
00:35:45.199 --> 00:35:49.159
doesn't work in the more complicate cases, mainly that if
646
00:35:50.159 --> 00:35:52.320
how do you register these endpoints?
647
00:35:53.039 --> 00:35:53.239
Right?
648
00:35:53.480 --> 00:35:56.880
Real apps have code splitting, so you might not load
649
00:35:56.920 --> 00:35:58.960
all the code in the client, or you might not
650
00:35:59.000 --> 00:36:02.000
load all the code on the server. And what ended
651
00:36:02.079 --> 00:36:05.840
up happening with the just doing a compiler approach was
652
00:36:06.000 --> 00:36:09.159
that we would sometimes navigate to a page on the
653
00:36:09.159 --> 00:36:13.119
client that hadn't been navigated to on the server, which
654
00:36:13.199 --> 00:36:15.800
means the endpoint wouldn't be registered yet.
655
00:36:15.639 --> 00:36:18.199
It didn't exist yet, so it didn't even occur to me.
656
00:36:18.920 --> 00:36:22.800
So like basically, this generic approach, it wasn't enough just
657
00:36:22.800 --> 00:36:25.079
to stop a babble and a compiler. We needed something
658
00:36:25.119 --> 00:36:28.239
that would actually go through the whole module graph and
659
00:36:28.960 --> 00:36:33.199
oist out these things, and it had to be bundler level.
660
00:36:33.320 --> 00:36:36.760
So this is that's that's actually why Blaine died. In
661
00:36:36.760 --> 00:36:38.480
a sense, Tannor has remade.
662
00:36:38.880 --> 00:36:42.880
It was repurposed, right. Actually, what's funny is like a
663
00:36:42.880 --> 00:36:46.519
lot of the code from Bling made it into VINI.
664
00:36:47.239 --> 00:36:50.159
Yes, yeah, yeah, I mean at the VAT.
665
00:36:50.039 --> 00:36:52.920
Level, right, And then what's funny is then eventually we
666
00:36:53.039 --> 00:36:54.400
ripped it back out.
667
00:36:54.719 --> 00:36:56.679
Right, and the other part of Vinci ended up going
668
00:36:56.679 --> 00:37:00.559
directly to VAT when VEAT adopted the environment's API, because
669
00:37:00.599 --> 00:37:04.920
we're building these things and the VAT team had, I
670
00:37:04.920 --> 00:37:07.239
guess their own problem with deployment, like the solved with
671
00:37:07.239 --> 00:37:09.440
the deployment environments, like you have cloud Flare, which is
672
00:37:09.440 --> 00:37:12.079
different than Netlify and Bursell, and you could build for
673
00:37:12.199 --> 00:37:15.800
like different outputs like workers versus pages and all these
674
00:37:15.840 --> 00:37:19.239
things people wanted to have, like you know and client preserved.
675
00:37:19.400 --> 00:37:23.599
They want to have these different environments. Vinci actually did
676
00:37:23.639 --> 00:37:26.440
that because VAT didn't. It was hard to manage these
677
00:37:26.519 --> 00:37:30.920
kind of things, and.
678
00:37:29.199 --> 00:37:31.000
That's why we created it. And in the end.
679
00:37:31.400 --> 00:37:33.960
As I said, VINCI now has kind of been dismantled,
680
00:37:34.320 --> 00:37:37.960
but the environment API now exists in Beat very similar
681
00:37:38.199 --> 00:37:40.199
seeing usage to how we used to do it in VINCI,
682
00:37:40.639 --> 00:37:45.559
and we still have the server functions plug in in
683
00:37:45.599 --> 00:37:48.400
the form of what what's under Tanstak that's now used
684
00:37:48.440 --> 00:37:51.039
both by Soul, certain tank Tack start Tanner.
685
00:37:51.320 --> 00:37:55.280
You're very polite. You raise your hand.
686
00:37:56.079 --> 00:37:59.760
Oh, I was. I was gonna say. One of your
687
00:38:00.039 --> 00:38:02.559
questions went unanswered, and I wanted to answer it before
688
00:38:02.599 --> 00:38:05.519
we went too deep into compiler land. And it was
689
00:38:05.559 --> 00:38:10.360
about type safety, and that is a massive part of
690
00:38:11.519 --> 00:38:16.159
another massive reason of why it all went this direction
691
00:38:16.239 --> 00:38:21.880
for me, and it's it's also because type safety. A
692
00:38:21.920 --> 00:38:24.599
lot of people think, well, it's just defining, you know,
693
00:38:24.880 --> 00:38:29.920
the types that this function can take on. But in
694
00:38:29.960 --> 00:38:34.360
reality you're not just writing typescript types and expecting those
695
00:38:34.400 --> 00:38:39.760
to get extracted away into validation. Because that's another that's
696
00:38:39.800 --> 00:38:42.960
another part where like just sending, just treating it like
697
00:38:43.000 --> 00:38:47.920
a function still is not totally safe. I mean, I
698
00:38:48.039 --> 00:38:49.840
like it that we that we want to get to
699
00:38:49.880 --> 00:38:52.960
this functional zintax of just calling the function and having
700
00:38:53.039 --> 00:38:57.000
it be awaited, and it's it's really nice, but under
701
00:38:57.000 --> 00:38:59.480
the hood, it's these details you need to be aware
702
00:38:59.519 --> 00:39:01.840
of them, and one of them is that you're going
703
00:39:01.840 --> 00:39:06.320
across the network. So type safety without validation is a
704
00:39:06.360 --> 00:39:11.320
complete lie. You can validate anytime you go across a
705
00:39:11.440 --> 00:39:15.960
serialization boundary, even into the URL or local storage, anywhere
706
00:39:16.400 --> 00:39:18.960
you have to validate or it's just a lie.
707
00:39:19.440 --> 00:39:22.719
So yeah, it's really I'll let you continue in a second.
708
00:39:22.719 --> 00:39:26.639
I'm just clarifying again the terminology. It's that distinction between
709
00:39:27.119 --> 00:39:31.000
dev time type safety, maybe even build time type safety
710
00:39:31.400 --> 00:39:33.800
and run time type safety.
711
00:39:33.480 --> 00:39:39.000
Static type checking versus actually run time validation.
712
00:39:38.960 --> 00:39:43.679
And exactly in Typescript very intentionally does not do any
713
00:39:44.239 --> 00:39:47.199
run type type checking. So the fact that you're building
714
00:39:47.400 --> 00:39:51.079
on that you're leveraging Typescript types is really cool. You
715
00:39:51.119 --> 00:39:55.320
get completion, you get squiggly lines during development, but at
716
00:39:55.400 --> 00:39:59.119
runtime over the network, anything might be sent, especially if
717
00:39:59.159 --> 00:40:01.159
it's like a public point.
718
00:40:00.880 --> 00:40:03.280
Right and you know, you might feel like you're just
719
00:40:03.360 --> 00:40:07.239
writing a function and it might feel secure, But no
720
00:40:07.280 --> 00:40:09.800
one in their right mind would create a rest endpoint
721
00:40:10.280 --> 00:40:14.159
straight into their back end and not validate the inputs
722
00:40:14.199 --> 00:40:18.719
that they're getting from people. And so the same way here,
723
00:40:18.760 --> 00:40:21.840
like you you want to be validating the inputs going
724
00:40:21.840 --> 00:40:26.960
across these functions in a special way that isn't just oh,
725
00:40:27.039 --> 00:40:29.320
it's a typescript type. So I'm just going to trust
726
00:40:29.360 --> 00:40:32.360
that I'm the only one calling it and that my
727
00:40:32.480 --> 00:40:34.599
system is the only one that has access to this
728
00:40:35.039 --> 00:40:39.239
public RPC endpoint. Like all this stuff is easily reverse
729
00:40:39.320 --> 00:40:41.800
engineered and abused.
730
00:40:42.119 --> 00:40:46.480
It's even worse because when you're doing posts like straight
731
00:40:46.559 --> 00:40:51.360
on RESTful APIs, you know that you know that you're
732
00:40:51.400 --> 00:40:53.400
going to have to check the types. You're going to
733
00:40:53.480 --> 00:40:55.119
have to effectively cast the types.
734
00:40:55.440 --> 00:40:59.519
Yeah, because when you're losing the types perfectly going into
735
00:40:59.559 --> 00:41:03.199
this exactly on transform mechanism and pulling them back out
736
00:41:03.280 --> 00:41:06.960
on the server side, you know you you have to
737
00:41:06.960 --> 00:41:09.519
do the same thing coming back out. Otherwise it's like, well,
738
00:41:09.519 --> 00:41:11.800
this is just a blob of whatever, you know.
739
00:41:13.679 --> 00:41:17.039
I think, yeah, and with and and I forget if
740
00:41:17.039 --> 00:41:20.519
it was Rich Harris or Lirental who literally showed me
741
00:41:20.599 --> 00:41:25.079
an example I think where they used typescript and instead
742
00:41:25.159 --> 00:41:29.360
of a certain value pass vr PC being like saying
743
00:41:29.440 --> 00:41:32.360
just a string, they said it needs to be like
744
00:41:33.679 --> 00:41:40.880
the quote unquote quote child or quote teacher and nothing
745
00:41:40.920 --> 00:41:43.639
at run time validates that some other string is not
746
00:41:43.760 --> 00:41:48.440
passed in so you so typescript literally lies to you
747
00:41:48.519 --> 00:41:51.159
in this case if you're not careful.
748
00:41:51.079 --> 00:41:54.159
Which typescript needs to come after that, which is it
749
00:41:54.199 --> 00:41:58.920
needs to be a byproduct. And that's exactly why we
750
00:41:58.920 --> 00:42:02.400
we did two things. One we adopted Standard Schema. I mean,
751
00:42:02.440 --> 00:42:06.760
we helped kind of push standard Schema into reality. It
752
00:42:06.800 --> 00:42:09.840
was created by all the brilliant people that build these
753
00:42:09.920 --> 00:42:16.679
validation libraries like yeah, like like ZOD and type, archetype
754
00:42:16.719 --> 00:42:19.840
and stuff like that. But but we needed validation, so
755
00:42:19.880 --> 00:42:22.639
we did validation first. And what's interesting is with with
756
00:42:22.719 --> 00:42:28.320
our APIs to create our PCs, we do not allow you.
757
00:42:29.440 --> 00:42:31.119
I mean, you can do anything you want, but I mean,
758
00:42:31.159 --> 00:42:35.159
the the happy path of our API is that you
759
00:42:35.239 --> 00:42:39.719
do not get types in your server functions in your
760
00:42:39.840 --> 00:42:45.119
rpcs unless you provide validation that gives you those types.
761
00:42:45.559 --> 00:42:48.159
If you try, like, we don't have a generic API
762
00:42:48.280 --> 00:42:53.440
to just cast the the types coming back with just
763
00:42:53.519 --> 00:42:57.280
typescript because we we think it's unsafe. So that is
764
00:42:57.320 --> 00:42:59.880
the happy path. You have to use a ZOD schema
765
00:43:00.079 --> 00:43:04.400
or an archetypes or whatever to to get that validation
766
00:43:04.719 --> 00:43:06.000
and turn it into types.
767
00:43:06.800 --> 00:43:08.840
It's funny how full circle this is going.
768
00:43:09.280 --> 00:43:11.480
And this happens to me a lot, I have to admit,
769
00:43:11.519 --> 00:43:16.960
because of the lookliness. Like the reason that RPC died
770
00:43:17.000 --> 00:43:20.280
in the first place was because it was clunky to
771
00:43:21.440 --> 00:43:23.760
in my opinion, there's many reasons, but part of it
772
00:43:23.840 --> 00:43:27.079
was that it was clunky to define stuff. And like
773
00:43:27.280 --> 00:43:30.199
it's a challenge like graft Tuel going away because you
774
00:43:30.199 --> 00:43:32.239
know you're defining these like.
775
00:43:32.159 --> 00:43:33.079
To define the types.
776
00:43:34.480 --> 00:43:38.599
So people get these Jason APIs and then and the
777
00:43:38.760 --> 00:43:41.199
people did the Jason on APIs and they like, you know,
778
00:43:41.559 --> 00:43:44.079
manage themselves, but it wasn't schema basis through the code
779
00:43:44.079 --> 00:43:44.719
at run time.
780
00:43:45.280 --> 00:43:47.400
And then like but there's a lots of holes there.
781
00:43:47.519 --> 00:43:50.480
So now people have reinforced on types, which obviously again
782
00:43:50.599 --> 00:43:53.000
gets us back to RPC. But like, it's funny the
783
00:43:53.039 --> 00:43:55.159
framework author's side, like let's say like deeper on the
784
00:43:55.239 --> 00:43:57.760
UI frame side, Like say, guys like myself or people
785
00:43:57.800 --> 00:44:00.000
working on React, we're looking at this and we're like, okay, McKenna,
786
00:44:00.639 --> 00:44:04.800
this works nice. It's ergonomic as thing. People can build
787
00:44:05.159 --> 00:44:07.719
stuff on top of it if they need to. But
788
00:44:08.239 --> 00:44:10.119
I have the pieces I need to do what I
789
00:44:10.159 --> 00:44:13.880
need to mechanically, and it's and it's smooth, but then
790
00:44:14.719 --> 00:44:17.000
we we get to a point where we add back
791
00:44:17.159 --> 00:44:20.400
our own friction because of like best practices.
792
00:44:21.360 --> 00:44:23.920
So that's what it was. Kind of kind of like the.
793
00:44:25.000 --> 00:44:27.559
Nice things on the web, that's truism.
794
00:44:28.400 --> 00:44:30.639
So yeah, it's kind of it's kind of interesting because
795
00:44:30.679 --> 00:44:32.360
because like, yeah, I mean, I love, you know, the
796
00:44:32.400 --> 00:44:34.599
standard schema, A big fan of Valabot and all that
797
00:44:34.639 --> 00:44:36.280
kind of stuff, But it's but it was, it's like
798
00:44:36.280 --> 00:44:38.199
one of those things where like the people building UI
799
00:44:38.280 --> 00:44:41.039
frameworks usually maybe the meta frameworks can, but the UI
800
00:44:41.119 --> 00:44:45.039
frameworks can't. Can't generally won't push those kind of things
801
00:44:45.039 --> 00:44:48.039
on you because they're like they're not they're not in
802
00:44:48.079 --> 00:44:50.559
our range of to be enforced because people will have
803
00:44:50.599 --> 00:44:52.159
different opinions, things will change over.
804
00:44:52.039 --> 00:44:55.480
Time, too much opinion coming from right exactly.
805
00:44:55.519 --> 00:44:57.280
So it's like we.
806
00:44:57.199 --> 00:44:59.400
Being a meta framework, then you get to enforce a
807
00:44:59.480 --> 00:45:00.800
little bit more those opinions.
808
00:45:00.920 --> 00:45:04.599
Yeah, it's just tricky because meta frameworks have a shorter
809
00:45:04.800 --> 00:45:06.760
shouldn't theory have a shorter shelf life?
810
00:45:06.519 --> 00:45:07.760
Because of that, Like.
811
00:45:08.239 --> 00:45:09.960
This was always the struggle I had on was work
812
00:45:09.960 --> 00:45:12.039
on all start because I like didn't want to make
813
00:45:12.119 --> 00:45:14.800
meta framework. I just wanted to make a like a
814
00:45:15.000 --> 00:45:17.440
create React app that work on the servers. This kind
815
00:45:17.440 --> 00:45:20.280
of kind of tension is interesting for the science space.
816
00:45:20.960 --> 00:45:23.519
There was something I wanted to say. You said, there's
817
00:45:23.519 --> 00:45:25.280
three things you need for rpcs to come back.
818
00:45:25.920 --> 00:45:30.920
Yeah, I mentioned, I'll said again, maybe it'll jog your memory. Basically,
819
00:45:31.079 --> 00:45:36.239
it was a type for the underlying system to be
820
00:45:36.400 --> 00:45:39.679
typed or type safe that at least a development time.
821
00:45:39.760 --> 00:45:43.400
Otherwise there's no point. So you probably wouldn't do RPC
822
00:45:43.519 --> 00:45:47.920
if you've just got JavaScript, a weight so that you
823
00:45:47.960 --> 00:45:52.679
can quote unquote block until that remote function finishes, and
824
00:45:53.239 --> 00:45:59.599
optionally the compiler slash bundler so that you can automatically
825
00:45:59.679 --> 00:46:02.840
general rate the stub code to do to translate that
826
00:46:02.960 --> 00:46:07.599
function called into you know, do the serializations, send the
827
00:46:07.639 --> 00:46:10.840
message across the wire, do the de serialization on the
828
00:46:10.840 --> 00:46:12.559
other side and back again?
829
00:46:13.119 --> 00:46:16.039
Right yeah, yeah, And you just mentioned it twice because
830
00:46:16.760 --> 00:46:19.320
I said at the beginning I wasn't trying to build RPC.
831
00:46:19.559 --> 00:46:22.360
I think the final piece that access cemented it for
832
00:46:22.480 --> 00:46:27.679
me was the serialization part. Because we don't communicate in
833
00:46:28.039 --> 00:46:30.559
Jason anymore with these you don't.
834
00:46:31.039 --> 00:46:32.760
No, no, no, I think.
835
00:46:32.639 --> 00:46:36.480
You do, don't you the call over the wire is
836
00:46:36.519 --> 00:46:40.079
it Jason or is it something else for server functions?
837
00:46:40.199 --> 00:46:45.440
Yeah, yes, by default, yes it's Jason. Yeah.
838
00:46:45.639 --> 00:46:48.639
See didn't And this is one of the attractive to
839
00:46:48.679 --> 00:46:51.119
be though. Yeah, this is one of the attractive things
840
00:46:51.119 --> 00:46:53.679
for us time because you can trouble sides. So this
841
00:46:53.760 --> 00:46:56.360
is like react love this, we love this, framework has
842
00:46:56.360 --> 00:46:58.079
love this. This is this is where you can go
843
00:46:58.119 --> 00:47:01.519
back and to what framework wanted is. At the exact
844
00:47:01.559 --> 00:47:03.599
same time I was working on this, we were updating
845
00:47:03.599 --> 00:47:07.119
our approach to doing streaming SSR and stuff, and we
846
00:47:07.159 --> 00:47:09.920
were making it faster and more efficient. Like every framework
847
00:47:09.960 --> 00:47:14.039
has their own serializer. Some are publicly available like solid seabo,
848
00:47:15.000 --> 00:47:21.280
Marco's warp nine devalue from spelp, and we were.
849
00:47:21.119 --> 00:47:23.159
Going to need to give a little bit more context
850
00:47:23.280 --> 00:47:25.960
I think. Okay, so to some of our listeners about
851
00:47:26.079 --> 00:47:28.719
why it is that you need this sort of civilization
852
00:47:28.880 --> 00:47:29.920
for SSR.
853
00:47:29.880 --> 00:47:31.239
I think that'll be really useful.
854
00:47:31.519 --> 00:47:32.440
Yeah, okay, sorry.
855
00:47:33.199 --> 00:47:36.000
Basically you're sending HTML, which you're like, okay, that's great,
856
00:47:36.599 --> 00:47:39.800
but the problem is now you have something ASIC so
857
00:47:41.280 --> 00:47:45.239
you can send the HTML in chunks. Let's say, so
858
00:47:45.280 --> 00:47:50.480
you're sending you know yes or it's streaming is basically
859
00:47:50.480 --> 00:47:54.880
the problem. You want to be able to not only
860
00:47:54.920 --> 00:47:58.119
send the HTML markup, but you want to be able
861
00:47:58.119 --> 00:48:01.239
to send the data across and if you wait for
862
00:48:01.280 --> 00:48:03.519
it all to finish, then just send the Jason and
863
00:48:03.559 --> 00:48:05.679
the HTML. Then you show the whole page at the end.
864
00:48:06.199 --> 00:48:09.519
But if you can, if you can send different types
865
00:48:09.559 --> 00:48:13.760
of serialization values, it's possible to send pieces of the
866
00:48:13.800 --> 00:48:16.679
app in parts and then for the client to go, oh,
867
00:48:17.360 --> 00:48:21.000
you serialize a promise, for example, and the client go okay,
868
00:48:21.159 --> 00:48:25.000
I know this data is coming. That's the most fundamental
869
00:48:25.039 --> 00:48:27.360
way of doing it, where we basically describe a promise
870
00:48:27.360 --> 00:48:29.880
over the wire. So when you know it starts hydrating
871
00:48:29.880 --> 00:48:31.480
part of the page and the whole page hasn't loaded
872
00:48:31.519 --> 00:48:34.000
in from the server, we can go okay, treat it
873
00:48:34.000 --> 00:48:36.320
like a client side promise, and we know that what
874
00:48:36.360 --> 00:48:38.920
will end up happening is actually on the same website page.
875
00:48:39.159 --> 00:48:42.599
We'll actually stream that Jason later, but then we'll when
876
00:48:42.599 --> 00:48:44.599
it comes in, we'll fulfill the promise on the client.
877
00:48:45.119 --> 00:48:50.920
So again, just to clarify the need, if I understand correctly,
878
00:48:51.079 --> 00:48:56.159
correct me if I'm wrong. It's it's your HTML intrinsic
879
00:48:56.280 --> 00:49:03.679
is intrinsically streaming. So the HTML protocol, unlike JavaScript, essentially
880
00:49:03.800 --> 00:49:06.440
you can stream it and it will just execute. The
881
00:49:06.559 --> 00:49:09.719
problem I think is the order of things is the
882
00:49:09.719 --> 00:49:14.960
fact that you that HTML streams top to bottom, whereas
883
00:49:15.119 --> 00:49:18.119
you want to be able to stream things and inject
884
00:49:18.119 --> 00:49:22.079
them in the middle of things that have already arrived. Right,
885
00:49:23.519 --> 00:49:26.719
and Tanner has raised his hand again, so interrupt.
886
00:49:26.880 --> 00:49:29.159
I just want to punctuate that and say that it's
887
00:49:29.639 --> 00:49:35.800
it's about order. It's about componentization of these calls to
888
00:49:35.800 --> 00:49:40.000
to say I have something that needs this amount of data,
889
00:49:40.880 --> 00:49:43.079
you know, and you can have multiples of those in
890
00:49:43.119 --> 00:49:46.679
whatever order you want, And inside of those responses you
891
00:49:46.760 --> 00:49:52.559
can have immediate, immediately returned partial parts of those responses
892
00:49:52.599 --> 00:49:55.280
and have some of them be delayed. So it's almost
893
00:49:55.360 --> 00:49:58.440
like you get the same experience inside of HTML where
894
00:49:58.480 --> 00:50:01.920
you can give the important stuff really quickly and delay
895
00:50:01.960 --> 00:50:04.960
the other stuff. You get that same capability within each
896
00:50:05.559 --> 00:50:07.360
request response life cycle.
897
00:50:07.880 --> 00:50:10.039
You can see it in this just just to say that.
898
00:50:10.119 --> 00:50:12.280
The joke that I like to say is that the
899
00:50:12.320 --> 00:50:16.280
big difference between old websites and modern websites is that
900
00:50:16.320 --> 00:50:19.039
we've replaced the single large spinner with a lot of
901
00:50:19.079 --> 00:50:20.199
small spinners.
902
00:50:21.480 --> 00:50:24.840
Yeah, we've been trying to solve that.
903
00:50:24.920 --> 00:50:25.159
I mean.
904
00:50:25.199 --> 00:50:28.199
The challenge is you can see in the shape that
905
00:50:28.320 --> 00:50:30.360
ht amount it self, it's x amount or you know,
906
00:50:30.400 --> 00:50:33.480
it's a markup language. So these things are naturally nested.
907
00:50:33.480 --> 00:50:34.960
You see it in your components. You have components and
908
00:50:34.960 --> 00:50:38.199
components and components and components. So like doing it top
909
00:50:38.239 --> 00:50:40.719
the bottom doesn't even work because the outer component hasn't closed,
910
00:50:40.760 --> 00:50:43.440
you know what I mean, like these envelopes. So what
911
00:50:43.599 --> 00:50:46.920
ends up happening is the trick to the h mell.
912
00:50:46.960 --> 00:50:50.880
Actually isn't that difficult mechanically because you can put it
913
00:50:50.920 --> 00:50:53.079
on the end in something invisible like a template, and
914
00:50:53.159 --> 00:50:57.199
have JavaScript move it back into place as it loads.
915
00:50:57.239 --> 00:50:59.519
The hard part is that is the data. If you
916
00:50:59.519 --> 00:51:02.039
actually want to wake up parts of that page before
917
00:51:02.079 --> 00:51:04.719
it all loads, you need to tell you need like
918
00:51:04.840 --> 00:51:08.159
a placeholder for the data. Essentially, you need to be like, look,
919
00:51:08.199 --> 00:51:10.440
this data will be coming or you know.
920
00:51:10.760 --> 00:51:14.800
And that's a promise and that's a problem or a substream.
921
00:51:15.280 --> 00:51:19.480
Right, So we started serializing well, I mean, and then
922
00:51:19.480 --> 00:51:22.199
there's different types of data right, like data objects, you know,
923
00:51:22.239 --> 00:51:25.639
and different things. So like even stuff like TRPC has
924
00:51:25.679 --> 00:51:29.000
like advanced like super JSON or like advanced data types
925
00:51:29.039 --> 00:51:31.920
you know. And but for us promises, we're the key
926
00:51:32.360 --> 00:51:35.639
for and we realized that we could bring that serialization
927
00:51:36.159 --> 00:51:38.519
not just in our original SSR, but use it in
928
00:51:38.599 --> 00:51:44.920
our server functions, so we could serialize anything, you know, HTML, elements, promises, whatever.
929
00:51:45.280 --> 00:51:48.760
And this meant that because both sides, RPC let both
930
00:51:48.760 --> 00:51:50.760
sides understand and this is in a sense like how
931
00:51:50.760 --> 00:51:53.559
server components work and React because they can go we
932
00:51:53.639 --> 00:51:57.400
have our special jsx on format and we can communicate
933
00:51:57.400 --> 00:51:59.639
both sides, and now we can communicate react components of
934
00:51:59.679 --> 00:52:02.039
the wire. As I said, our needs are a little
935
00:52:02.039 --> 00:52:05.119
bit simpler with like promises and streams, but it works
936
00:52:05.119 --> 00:52:08.199
out kind of similar. We it lets us build on
937
00:52:08.440 --> 00:52:12.159
really powerful capabilities on this because you can say, return
938
00:52:12.239 --> 00:52:15.280
some data with a promise encoded in it, and then
939
00:52:15.320 --> 00:52:17.119
like have the data come back in chunks.
940
00:52:17.119 --> 00:52:17.920
You can make an.
941
00:52:17.760 --> 00:52:20.679
ACYNC iterable and basically return the stream so the server
942
00:52:20.760 --> 00:52:23.719
can just keep on yielding data into your server function.
943
00:52:23.960 --> 00:52:26.639
And you write it literally as like an ACE generator function.
944
00:52:26.679 --> 00:52:28.960
So you write it as a like an acing function,
945
00:52:29.320 --> 00:52:33.519
and it'll our generator word yields and will literally be
946
00:52:33.599 --> 00:52:37.360
yielding from server to client. So there's a lot of
947
00:52:37.400 --> 00:52:39.440
really cool mechanics here.
948
00:52:39.639 --> 00:52:43.519
Do you support that in? I know that Quick supports that.
949
00:52:43.679 --> 00:52:46.000
I know that, or RBC supports that. Do you guys
950
00:52:46.000 --> 00:52:50.840
also support that that the ability to stream a response
951
00:52:50.920 --> 00:52:52.280
from ann RBC?
952
00:52:53.159 --> 00:52:56.480
Yeah, Salades, Yeah, it's in. It's in, Sarah Belle. I
953
00:52:56.480 --> 00:52:58.400
don't know if someone Start handles it the best in
954
00:52:58.400 --> 00:53:01.199
all cases, but the core technology support to it.
955
00:53:01.159 --> 00:53:06.679
So I guess side uh side quest here is we
956
00:53:06.679 --> 00:53:10.880
we and we started out building our own serializer I
957
00:53:10.920 --> 00:53:15.159
did for tansex Start that was had. It was a
958
00:53:15.199 --> 00:53:20.079
little bit lighter than something like sarahvel Or or the
959
00:53:20.119 --> 00:53:23.239
big giant serializer that that can do like re ex
960
00:53:23.280 --> 00:53:27.440
server components and stuff. And there's also super Jason there.
961
00:53:27.519 --> 00:53:29.960
There's even one that the remix team built right for
962
00:53:30.039 --> 00:53:30.760
react about.
963
00:53:30.880 --> 00:53:33.719
Somebody on the chat called it a tool boards.
964
00:53:33.079 --> 00:53:35.400
Cha Jason, Right, Yeah, there's there's a couple of these,
965
00:53:36.639 --> 00:53:39.239
and and I wrote a simple one that would kind
966
00:53:39.239 --> 00:53:43.039
of get to m v P for tansex Start Alpha.
967
00:53:43.159 --> 00:53:46.880
And even even the simple one could serialized promises and
968
00:53:46.960 --> 00:53:51.880
serialized streams. But then we we realized that we want
969
00:53:51.920 --> 00:53:56.039
to do more complex stuff. We've decided to adopt Sarahvell.
970
00:53:58.119 --> 00:54:02.239
I think I told you that, Ryan, right, okay for you.
971
00:54:03.199 --> 00:54:06.000
We so we have one that works for tansax start,
972
00:54:06.039 --> 00:54:11.199
but we're adopting Sarall because is beyond just being able
973
00:54:11.199 --> 00:54:13.880
to stream this stuff. Sarahville has some very unique So.
974
00:54:13.800 --> 00:54:16.519
What is Serville I think I missed explanation.
975
00:54:16.800 --> 00:54:20.440
It's it's the serializer used by SOLODJS use both in
976
00:54:20.480 --> 00:54:22.960
our server rendering and in our server functions. I was
977
00:54:22.960 --> 00:54:27.880
built by Alexis Monselek core team members sologs and yeah.
978
00:54:28.519 --> 00:54:33.599
It's basically serializes stuff over the wire and then de
979
00:54:33.719 --> 00:54:37.920
serialize it. But it's not exactly Jason. It's something else,
980
00:54:39.079 --> 00:54:42.239
like like React doesn't use Jason either. In case people
981
00:54:42.239 --> 00:54:42.719
don't know.
982
00:54:42.840 --> 00:54:43.519
For their.
983
00:54:44.800 --> 00:54:48.400
Responses from server from server components, you.
984
00:54:48.360 --> 00:54:50.199
See a lot of them that have like it's it's
985
00:54:50.239 --> 00:54:54.119
like a superset of Jason that they then encode and
986
00:54:54.159 --> 00:54:57.480
decode special characters, special things.
987
00:54:57.519 --> 00:55:00.320
Look for at the very least, you won't command lines
988
00:55:00.320 --> 00:55:02.760
separate the Jason in order to be able to send
989
00:55:02.800 --> 00:55:07.039
multiple messages and not be kind of stuck on on
990
00:55:07.159 --> 00:55:09.519
not closing the bracket or something.
991
00:55:10.679 --> 00:55:15.199
Is I think Saravel is very unique and really cool
992
00:55:15.239 --> 00:55:21.079
because Saravel does not Servell uses javascripts essentially to stream
993
00:55:21.320 --> 00:55:25.840
like to serialize all of this. Saravel uses JavaScript and
994
00:55:25.920 --> 00:55:28.519
streams it and executes it over the wire, and it
995
00:55:28.639 --> 00:55:32.760
is it's incredible to watch it work. Because even beyond that,
996
00:55:32.840 --> 00:55:39.119
I mean super JC yeah, a little bit. Yes, I
997
00:55:39.119 --> 00:55:40.280
wouldn't want to call it that.
998
00:55:40.159 --> 00:55:41.800
But yeah, I mean there is a bit of that.
999
00:55:42.239 --> 00:55:45.880
And in some cases where the security isn't concerned, he's
1000
00:55:46.079 --> 00:55:49.519
he's been looking at alternate serialization formats so that you
1001
00:55:50.079 --> 00:55:54.760
don't have the evil aspect of it. But yeah, it is,
1002
00:55:54.760 --> 00:55:57.400
it is, there is there's.
1003
00:55:56.440 --> 00:55:58.599
Great power comes great responsibility.
1004
00:55:58.880 --> 00:56:01.360
But I mean the power is incredible because this is
1005
00:56:01.519 --> 00:56:05.360
this is what enables future facing patterns. We've never had
1006
00:56:05.480 --> 00:56:08.679
things like single page apps be able to easily do
1007
00:56:09.239 --> 00:56:13.559
basically picture. You know, people familiar with React query where
1008
00:56:13.599 --> 00:56:16.239
you can like do a mutation and invalidate like a
1009
00:56:16.239 --> 00:56:20.440
couple of queries. What if you can do the mutation
1010
00:56:21.159 --> 00:56:23.079
so send it to the server and have the server
1011
00:56:24.000 --> 00:56:27.280
figure out what the invalidate and then while it's still there.
1012
00:56:27.360 --> 00:56:30.159
Start fetching the data, that data on the server and
1013
00:56:30.199 --> 00:56:32.920
send it back, you know, like return right away from
1014
00:56:32.960 --> 00:56:35.920
your mutation, but then have it streaming back the data
1015
00:56:36.000 --> 00:56:37.760
for like the next page you're going to visit right.
1016
00:56:37.800 --> 00:56:39.280
If you have the knowledge of say like a router,
1017
00:56:39.719 --> 00:56:43.400
and you have this capability of serialization, you can do
1018
00:56:43.800 --> 00:56:45.760
like single flight mutations and stuff.
1019
00:56:45.960 --> 00:56:48.800
Crap is gonna restart because of not.
1020
00:56:48.719 --> 00:56:54.519
Just single mutations, but stream Yeah, for a minute or so,
1021
00:56:54.800 --> 00:57:01.719
I'll be back. It looks like, but you'll yeah, it's
1022
00:57:02.039 --> 00:57:04.320
not that it's single flight mutations doesn't been around forever,
1023
00:57:04.400 --> 00:57:07.519
but I mean that's how the web worked anyway. But
1024
00:57:08.800 --> 00:57:11.159
single flight mutations that are streamed, I think that's the
1025
00:57:11.159 --> 00:57:13.719
most important part of it. It's like as you get
1026
00:57:13.719 --> 00:57:15.719
the response, as you get the requests on the server,
1027
00:57:16.119 --> 00:57:18.800
and you start processing things that need to change, you
1028
00:57:19.039 --> 00:57:22.119
don't again, don't need to wait to know all of
1029
00:57:22.119 --> 00:57:23.920
the changes that are going to happen to send them
1030
00:57:23.920 --> 00:57:27.079
back to the client. You can start processing them and
1031
00:57:27.119 --> 00:57:31.800
shipping them as you find them to the client. That
1032
00:57:31.800 --> 00:57:36.599
that is incredible, so that you know you're in Validation
1033
00:57:36.800 --> 00:57:40.320
from the server can essentially be streamed in as soon
1034
00:57:40.400 --> 00:57:42.239
as you know about it to the client in the
1035
00:57:42.280 --> 00:57:43.039
same request.
1036
00:57:43.880 --> 00:57:46.480
The funny thing, though, is that that kind of goes
1037
00:57:46.559 --> 00:57:51.320
beyond RPC. That's more in the territory of SSR, isn't it.
1038
00:57:51.719 --> 00:57:56.880
No, Because we're still just talking about individual requests an
1039
00:57:57.000 --> 00:58:02.960
RPC for instance, to say, you know, I want to
1040
00:58:02.800 --> 00:58:05.599
go the base query maybe and then or say I
1041
00:58:05.639 --> 00:58:08.159
want to update a user. I want to update a
1042
00:58:08.280 --> 00:58:12.360
user capability. Right, I'm adding a capability to a user,
1043
00:58:12.840 --> 00:58:16.079
and you you go to add that capability on the
1044
00:58:16.119 --> 00:58:20.000
server side, You'll you'll receive that mutation, You'll you'll create
1045
00:58:20.039 --> 00:58:22.039
that mutation, and then you're probably going to have a
1046
00:58:22.079 --> 00:58:25.119
bunch of other things that need to be invalidated for
1047
00:58:25.199 --> 00:58:27.880
the user or refresh or streams to the user that
1048
00:58:27.920 --> 00:58:30.639
are going to be new. With that new capability, they'll
1049
00:58:30.639 --> 00:58:36.519
gain access to new items, new things, new collection types
1050
00:58:36.559 --> 00:58:40.679
inside of their application, and some of those items might
1051
00:58:40.679 --> 00:58:45.079
take longer for you to fetch on the server and
1052
00:58:45.119 --> 00:58:48.079
give to them than others, So out of the gate,
1053
00:58:48.519 --> 00:58:50.960
you'll want to ship them a new user object that'll
1054
00:58:50.960 --> 00:58:53.000
be really fast, So you ship that down in the
1055
00:58:53.039 --> 00:58:56.719
same response, you push that down, and then you're still
1056
00:58:56.760 --> 00:58:59.880
working on maybe maybe their team data or their work
1057
00:59:00.039 --> 00:59:02.519
based data, and then as you get those, you ship
1058
00:59:02.599 --> 00:59:06.039
those down as well, and so you can start in
1059
00:59:06.079 --> 00:59:10.360
the same request of just a mutation, the response can contain,
1060
00:59:10.840 --> 00:59:15.440
you know, immediate and streamed data. It's really interesting.
1061
00:59:16.079 --> 00:59:17.840
First of all, you're turning on a lot of light
1062
00:59:17.880 --> 00:59:21.400
bulbs for me, so thank you for that, and you're
1063
00:59:21.599 --> 00:59:25.920
raising and it's interesting because what I'm thinking. I'm old
1064
00:59:26.039 --> 00:59:29.760
enough to remember the original RPC implementations back in the
1065
00:59:29.840 --> 00:59:33.880
nineties and one of the main problems with them was
1066
00:59:34.000 --> 00:59:40.840
the fact that they were built as being synchronous type operations,
1067
00:59:41.519 --> 00:59:45.360
and because the assumption was that it is kind of
1068
00:59:45.480 --> 00:59:50.199
like a function and function calls usually are cheap, so
1069
00:59:50.519 --> 00:59:53.320
you can make one function call for the fast stuff
1070
00:59:53.320 --> 00:59:56.039
and another function called for the for the slow stuff,
1071
00:59:56.159 --> 00:59:59.280
or get the call back or stuff like that, and
1072
00:59:59.679 --> 01:00:02.239
they did I didn't really accommodate for that scenario that
1073
01:00:02.280 --> 01:00:07.800
you're describing, where I'm requesting multiple data items and they
1074
01:00:07.840 --> 01:00:12.039
are available at different at different times, and that I
1075
01:00:12.199 --> 01:00:17.199
can create this kind of a sophisticated staggered response that
1076
01:00:17.599 --> 01:00:20.760
data arrives as soon as it's available, and I don't
1077
01:00:20.760 --> 01:00:23.639
need to make multiple calls in order to get all
1078
01:00:23.639 --> 01:00:27.480
this data. Yeah, I'm giving them mic back to you.
1079
01:00:28.760 --> 01:00:32.440
I think that it even goes He takes that even further.
1080
01:00:32.760 --> 01:00:34.880
Is yes, it works for data that you request you
1081
01:00:34.920 --> 01:00:37.320
may know about, but it also works for data that
1082
01:00:37.440 --> 01:00:40.320
maybe you don't want to know about but needs to
1083
01:00:40.360 --> 01:00:45.000
be sent. Is it leaves room now for this hidden
1084
01:00:45.440 --> 01:00:51.320
layer of meta data, of meta actions or meta code
1085
01:00:51.360 --> 01:00:54.119
that could happen with a request response. So, for example,
1086
01:00:54.840 --> 01:00:58.760
the developer experience that I would want as a developer
1087
01:00:58.960 --> 01:01:02.599
when I say update this user capability, I just want
1088
01:01:02.639 --> 01:01:06.719
to update that user capability. I don't want to I
1089
01:01:06.760 --> 01:01:10.360
don't want to have to be responsible for receiving and
1090
01:01:11.679 --> 01:01:14.360
acting on all of this extra data coming back to
1091
01:01:14.400 --> 01:01:16.280
me though. I just want to trust that it's going
1092
01:01:16.320 --> 01:01:18.400
to work. And so naturally, what do a lot of
1093
01:01:18.440 --> 01:01:19.960
people would say is that say, well, I'm going to
1094
01:01:20.039 --> 01:01:22.559
update this user with a new capability, and then they
1095
01:01:22.599 --> 01:01:25.199
get it back, and what do they expect. They expect
1096
01:01:25.360 --> 01:01:28.840
the response to be a user and the new version
1097
01:01:28.840 --> 01:01:32.239
of the user that has the updated capability. What they're
1098
01:01:32.280 --> 01:01:35.000
not going to expect is to have a bunch of
1099
01:01:35.119 --> 01:01:40.199
other random, you know, data invalidation payloads that they now
1100
01:01:40.239 --> 01:01:43.519
have to handle. So what's nice about something like Sarah
1101
01:01:43.559 --> 01:01:47.199
Bell is that it's it's not just you know, this
1102
01:01:47.440 --> 01:01:50.400
super set of Jason or whatever, but it's the ability
1103
01:01:50.480 --> 01:01:53.880
for even frameworks or middlewares or things in the middle
1104
01:01:53.920 --> 01:01:58.400
of that operation more code can just be sent down
1105
01:01:58.480 --> 01:02:01.800
to the client to execute that the response doesn't even
1106
01:02:01.840 --> 01:02:06.000
need to handle or know about. So it leaves a
1107
01:02:06.039 --> 01:02:10.960
lot of room for optimizations and frameworks to get into
1108
01:02:11.000 --> 01:02:14.519
this request response life cycle, but still keep the developer
1109
01:02:14.599 --> 01:02:17.519
developer experience really lean, not.
1110
01:02:17.599 --> 01:02:20.119
Meaning it means, but a little bit scary because if
1111
01:02:20.119 --> 01:02:23.599
I'm understanding correctly what you're saying is, let's say I
1112
01:02:23.679 --> 01:02:28.960
want to get the new user an updated user object
1113
01:02:29.000 --> 01:02:33.400
from the server. So I do an RPC call, I
1114
01:02:33.599 --> 01:02:36.519
get back the new user, and I do with it
1115
01:02:36.639 --> 01:02:39.239
whatever I do with it. But it turns out that
1116
01:02:39.760 --> 01:02:43.119
it also realized that some group that the user belongs
1117
01:02:43.159 --> 01:02:47.400
to updated, so it sends that down as well. I
1118
01:02:47.440 --> 01:02:51.159
don't handle it because I don't expect it, so I
1119
01:02:51.239 --> 01:02:53.559
didn't even write the code to handle it, but it
1120
01:02:53.679 --> 01:02:57.079
also sent the code that will handle it for me.
1121
01:02:57.280 --> 01:02:59.400
If I understand correctly, what you're kind.
1122
01:02:59.199 --> 01:03:02.480
Of it depends. It depends. A lot of this gets
1123
01:03:02.519 --> 01:03:07.159
into how you use such a tool, right, Yes, you
1124
01:03:07.239 --> 01:03:10.079
could stream down the code that handles it as well,
1125
01:03:10.119 --> 01:03:13.480
but more than likely that kind of code would live
1126
01:03:13.519 --> 01:03:16.000
on the client. It would live on the client side.
1127
01:03:16.599 --> 01:03:20.920
To say, we are orchestrating this metadata layer right as
1128
01:03:20.960 --> 01:03:23.719
the client. We know that we're going to want this
1129
01:03:23.840 --> 01:03:25.760
extra metadata to invalidate.
1130
01:03:25.880 --> 01:03:28.239
So it's a callback that I attached that one, or
1131
01:03:28.280 --> 01:03:31.679
middleware that I attach that gets invoked with the extra
1132
01:03:31.840 --> 01:03:36.039
data that happened to arrive on because of some other
1133
01:03:36.199 --> 01:03:37.880
call that caused it to be sent.
1134
01:03:38.159 --> 01:03:41.039
And we're talking about middleware that can span the client
1135
01:03:41.079 --> 01:03:43.440
and the server just like a server function. Right, it's
1136
01:03:43.480 --> 01:03:48.639
middleware that can compose together inside of this system that's
1137
01:03:48.719 --> 01:03:52.599
extracting into client and server and creating. It's RPC middleware
1138
01:03:52.880 --> 01:03:53.519
essentially what.
1139
01:03:53.480 --> 01:03:57.679
It is, correct, I'm trying to think of an actual
1140
01:03:57.960 --> 01:04:02.960
valid scenario and you tell me if it kind of matches.
1141
01:04:03.679 --> 01:04:07.280
So I know that a lot of times as secure
1142
01:04:07.320 --> 01:04:12.360
systems have this concept of a refresh token. So if
1143
01:04:12.440 --> 01:04:16.599
your access token in validates, you have a refresh stoken
1144
01:04:16.639 --> 01:04:19.559
that generates a new access token for you, and that
1145
01:04:19.760 --> 01:04:22.320
happens behind the scenes. You don't need to be aware
1146
01:04:22.360 --> 01:04:25.239
of this whole thing or this whole mechanism going on.
1147
01:04:25.360 --> 01:04:27.719
So is it something kind of like that.
1148
01:04:27.960 --> 01:04:30.480
I don't know if I would use this for that.
1149
01:04:31.360 --> 01:04:34.719
I mean you could, No, I'm just thinking about the
1150
01:04:34.840 --> 01:04:39.840
scenario where you're making a function call for a but
1151
01:04:40.000 --> 01:04:43.320
that triggers also other stuff to take place in the
1152
01:04:43.400 --> 01:04:46.679
system that you may not necessarily be aware of.
1153
01:04:47.000 --> 01:04:50.800
Yeah. I think what we're mostly talking about here is optimizations, right,
1154
01:04:50.920 --> 01:04:53.440
kind of like the example that Ryan brought up is
1155
01:04:53.440 --> 01:04:58.159
like you send off pre crashing. Yeah, you send off
1156
01:04:58.159 --> 01:05:01.440
a request with a mutation and the intent is known
1157
01:05:01.480 --> 01:05:04.440
that you're going to be at this destination next. Instead
1158
01:05:04.480 --> 01:05:08.440
of waiting for all of this to to settle, the
1159
01:05:08.519 --> 01:05:10.840
dust to settle before you go request the assets for
1160
01:05:10.920 --> 01:05:13.719
your next destination, you can do all of this in
1161
01:05:13.760 --> 01:05:17.039
one request. You can send all of the assets that
1162
01:05:17.079 --> 01:05:19.159
are going to be requested anyway.
1163
01:05:19.239 --> 01:05:21.559
Yeah, it's it's kind of interesting.
1164
01:05:21.199 --> 01:05:23.079
Kind of resource sense in a sense.
1165
01:05:23.920 --> 01:05:24.159
Yeah.
1166
01:05:24.320 --> 01:05:27.559
What I found kind of interesting about this resource.
1167
01:05:27.159 --> 01:05:29.000
Pushing resource pushing.
1168
01:05:29.079 --> 01:05:32.440
Yeah, when I when I was working on the solution,
1169
01:05:32.719 --> 01:05:35.079
was the kind of that realization is that people are
1170
01:05:35.079 --> 01:05:38.639
already writing their code mostly isomorphically, which means that like
1171
01:05:38.679 --> 01:05:42.800
they're already creating these patterns. So like running the say
1172
01:05:42.800 --> 01:05:46.920
the routeloaders again on the server and a mutation and
1173
01:05:47.000 --> 01:05:50.119
then expecting the code to be basically the same on
1174
01:05:50.199 --> 01:05:53.320
the client because it is the same code it's source
1175
01:05:53.400 --> 01:05:57.000
code basically gives you this ability. So like what was
1176
01:05:57.039 --> 01:05:59.960
kind of cool is yeah, the kind of optimization look
1177
01:06:00.079 --> 01:06:02.599
you can go in because if you're in a nested route,
1178
01:06:02.599 --> 01:06:04.519
if you're familiar with nest to routing, maybe the top
1179
01:06:04.559 --> 01:06:08.199
section doesn't change, only the like the two sections underneath
1180
01:06:08.280 --> 01:06:10.480
swap on this navigation, so you're like you're staying on
1181
01:06:10.480 --> 01:06:12.280
the same main page and then you go to the
1182
01:06:12.280 --> 01:06:14.840
next page. Well, if that data from the top main
1183
01:06:14.880 --> 01:06:17.559
page isn't being updated, then you don't have to fetch
1184
01:06:17.559 --> 01:06:20.480
it again on the server loaders. Like basically we were
1185
01:06:20.679 --> 01:06:24.519
able to use the same sort of knowledge of what
1186
01:06:24.679 --> 01:06:28.559
route changes and what data is already available based on
1187
01:06:29.039 --> 01:06:34.920
what things it would fetch when it navigates to those pages,
1188
01:06:35.480 --> 01:06:38.599
to the point that we basically go, Okay, this is
1189
01:06:38.639 --> 01:06:40.440
already there and the client don't need the updated and
1190
01:06:40.480 --> 01:06:43.440
it hasn't explicitly invalidated. This is already there, this is new,
1191
01:06:43.800 --> 01:06:46.880
this isn't just on this page, this has been updated.
1192
01:06:46.960 --> 01:06:50.679
And then fetch those things and put them on that request.
1193
01:06:50.760 --> 01:06:52.960
But the client are the server responds right away. So
1194
01:06:53.000 --> 01:06:55.320
the server goes, okay, we're going to redract to this
1195
01:06:55.400 --> 01:06:58.440
next page, and the client goes, okay, I'm going to
1196
01:06:58.480 --> 01:07:00.920
go to this next page. So the client goes to
1197
01:07:00.960 --> 01:07:04.280
that next page. But because those promise stubs are there,
1198
01:07:05.519 --> 01:07:07.400
when it goes to load the data, it goes, oh, no,
1199
01:07:07.480 --> 01:07:10.960
promise stub right here, it's already in the cash. I'm
1200
01:07:10.960 --> 01:07:13.360
going to use this promise instead of fetching it again
1201
01:07:14.119 --> 01:07:17.000
for the stuff that's new. So it's it's kind of
1202
01:07:17.719 --> 01:07:20.199
it's weird how you can kind of like do this
1203
01:07:20.280 --> 01:07:23.239
kind of predictively, but in the end, what you end
1204
01:07:23.320 --> 01:07:25.199
up with, which is my favorite part about this, is
1205
01:07:25.559 --> 01:07:28.119
you're actually leveraging your knowledge of the client side cash
1206
01:07:28.119 --> 01:07:31.159
on the server here, so you actually don't need cashing
1207
01:07:31.280 --> 01:07:34.360
on the server in this mechanism. Like you could still
1208
01:07:34.400 --> 01:07:36.360
optimize it with like a rettis or something, but we
1209
01:07:36.760 --> 01:07:39.719
never went through that whole Next DS use cash dilemma
1210
01:07:40.039 --> 01:07:42.840
or cash stup because when you do server functions, you
1211
01:07:42.880 --> 01:07:44.519
re render the whole page. It's kind of like remix.
1212
01:07:44.559 --> 01:07:47.199
It's like that loader bit. You know the whole route sections.
1213
01:07:47.320 --> 01:07:49.239
So when you hit a you have five data points, well,
1214
01:07:49.239 --> 01:07:51.719
guess what, you are fetching all five data points.
1215
01:07:51.719 --> 01:07:54.920
There's no way for you to separate those apart.
1216
01:07:54.679 --> 01:07:56.280
Which means that if you don't want to refetch all
1217
01:07:56.320 --> 01:07:58.679
five data points every single time, you are going to
1218
01:07:58.719 --> 01:08:01.320
cash them on the server. This approach you'll let you
1219
01:08:01.400 --> 01:08:04.559
basically use the knowledge of the route and the knowledge
1220
01:08:04.559 --> 01:08:07.840
of the invalidation from the mutation to actually only fetch
1221
01:08:07.840 --> 01:08:11.159
what's needed, so server cashes aren't necessary. It feels like
1222
01:08:11.159 --> 01:08:12.760
a single page app word. You know, the cache is
1223
01:08:12.840 --> 01:08:15.960
on the client, but it's actually doing this all in
1224
01:08:15.960 --> 01:08:16.680
a single.
1225
01:08:16.880 --> 01:08:20.199
So again, let me see if I'm getting this, because
1226
01:08:21.079 --> 01:08:23.560
to an extent, it's kind of incidental to the fact
1227
01:08:23.560 --> 01:08:27.680
that it's RPC. It's basically the fact that you're controlling
1228
01:08:28.439 --> 01:08:31.479
both sides and the protocol that lets you do a
1229
01:08:31.520 --> 01:08:34.239
lot of magic. The fact that it's RPC, like I said,
1230
01:08:34.239 --> 01:08:38.439
it's almost incidental. It might have been some other mechanism.
1231
01:08:39.279 --> 01:08:40.720
But what you're.
1232
01:08:40.640 --> 01:08:44.880
Saying is this, I'm triggering an operation to receive data.
1233
01:08:45.920 --> 01:08:59.159
I know that this operation will likely trigger redirection or
1234
01:08:59.479 --> 01:09:06.600
transition to another page. I can prefetch or push more accurately.
1235
01:09:06.680 --> 01:09:09.920
I can like you said tenor I use the wrong analogy,
1236
01:09:09.960 --> 01:09:13.359
because it's not client instigated, its server instigated. The server
1237
01:09:13.560 --> 01:09:18.039
side knows that I'm likely going to be needing that
1238
01:09:18.159 --> 01:09:23.479
additional data. I can send it down, hold it somewhere
1239
01:09:23.479 --> 01:09:27.039
in the client side so that when I actually needed
1240
01:09:27.159 --> 01:09:28.119
it's already there.
1241
01:09:28.760 --> 01:09:33.640
Basically, and that becomes even more powerful as you stream,
1242
01:09:34.399 --> 01:09:37.680
because we could do this before with single flight mutation.
1243
01:09:37.800 --> 01:09:41.079
As you send it, and if you spend enough time
1244
01:09:41.119 --> 01:09:43.560
on the server, you can gather up all of the
1245
01:09:43.640 --> 01:09:46.840
data and finally send it all back and then allow
1246
01:09:46.880 --> 01:09:51.920
the user to navigate. But streaming allows you to respond immediately,
1247
01:09:52.640 --> 01:09:57.039
but tick off those requests server side and then stream
1248
01:09:57.079 --> 01:10:01.840
them down to the user and utilize utilize that connection
1249
01:10:01.920 --> 01:10:02.800
that's already open.
1250
01:10:02.920 --> 01:10:06.439
It's because the frameworks support a signatively. Things like suspense
1251
01:10:07.119 --> 01:10:10.479
basically will trigger and treat your cached promise or your
1252
01:10:10.720 --> 01:10:13.720
pre pushed promise, and a new promise would fetch identically.
1253
01:10:14.119 --> 01:10:17.880
So in these kind of scenarios, you actually get further ahead.
1254
01:10:18.000 --> 01:10:20.760
You can start rendering the next page before that data
1255
01:10:20.920 --> 01:10:21.560
has arrived.
1256
01:10:22.960 --> 01:10:26.319
And the fact that we're componentized kind of necessitates this
1257
01:10:26.399 --> 01:10:29.640
whole thing because otherwise one of the big problems with
1258
01:10:30.159 --> 01:10:35.439
components is that in capsulation, if you're following through on
1259
01:10:35.479 --> 01:10:41.479
it often leads to waterfalls. So the fact and react
1260
01:10:41.520 --> 01:10:44.560
query it back of the day at the time was
1261
01:10:44.840 --> 01:10:49.439
so great in this regard because you fetched from one
1262
01:10:49.479 --> 01:10:52.920
component and then it got reused the data in other
1263
01:10:53.000 --> 01:10:59.039
components without you needing to like break in capsulation be
1264
01:10:59.279 --> 01:11:03.000
very iplicit about it. It was totally implicit. So now
1265
01:11:03.000 --> 01:11:05.520
you're kind of taking it to the next level in
1266
01:11:05.560 --> 01:11:07.720
a sense this and this.
1267
01:11:08.000 --> 01:11:10.439
Opens up new can of worms. I don't know how
1268
01:11:10.439 --> 01:11:12.720
deeply you want to get into that, but components have
1269
01:11:12.800 --> 01:11:17.399
you on again component level data fetching it. I'm still
1270
01:11:18.319 --> 01:11:21.640
I think it's still really the way to go. And
1271
01:11:21.680 --> 01:11:27.199
then thinking about thinking about the the optimizations that need
1272
01:11:27.279 --> 01:11:30.800
to be made at the routing level and the SEO
1273
01:11:30.960 --> 01:11:33.479
level and the page levels to get rid of waterfalls,
1274
01:11:33.479 --> 01:11:36.880
and that you know these are optimizations and making those
1275
01:11:36.880 --> 01:11:41.359
optimizations as easy as we can is really important, and
1276
01:11:41.439 --> 01:11:45.159
we can do that through API design with our routing.
1277
01:11:45.359 --> 01:11:48.960
We could do it through compilers like relay, but they
1278
01:11:49.039 --> 01:11:52.760
are optimizations. I think at that point, I like this,
1279
01:11:53.279 --> 01:11:55.039
I like everything that we've talked about is really.
1280
01:11:55.119 --> 01:11:57.439
I interrupt you again because I have to say that
1281
01:11:57.600 --> 01:12:00.760
one of the biggest downfalls of RP see back in
1282
01:12:00.800 --> 01:12:03.760
the old days, and one that I was so concerned
1283
01:12:03.800 --> 01:12:06.760
with that I actually at the end of my presentation
1284
01:12:06.920 --> 01:12:10.319
or RPC, I talk about the potential downsides of RPC,
1285
01:12:10.439 --> 01:12:13.520
and it's one of the items listed there is the
1286
01:12:13.560 --> 01:12:20.000
fact that RPC kind of encourages waterfalls because you make
1287
01:12:20.039 --> 01:12:22.760
a function call to get some data, and then you
1288
01:12:22.840 --> 01:12:25.880
make another function call to get some more data, and
1289
01:12:25.960 --> 01:12:28.520
another function called to get some more data, so you
1290
01:12:28.640 --> 01:12:34.319
end up with chatty protocols and waterfalls because the implicit
1291
01:12:34.359 --> 01:12:37.479
assumption is that it works like functions and functions are cheap.
1292
01:12:38.479 --> 01:12:43.199
And what you're saying is that you're overcoming it by
1293
01:12:43.439 --> 01:12:47.359
being smart realizing you know, you can still write it
1294
01:12:47.039 --> 01:12:51.800
like it is if it's a waterfall, but you've triggered
1295
01:12:51.840 --> 01:12:55.039
the requests, the generation of the code that's going to
1296
01:12:55.079 --> 01:12:58.399
be requested in the third request, in the first request,
1297
01:12:58.600 --> 01:13:02.439
and already be even scented down, so by the time
1298
01:13:02.520 --> 01:13:06.479
I get to that third RPC call, it's returning immediately
1299
01:13:06.600 --> 01:13:08.359
because all the data is already there.
1300
01:13:08.520 --> 01:13:12.800
Yeah, we're getting into what I would call orchestration of
1301
01:13:12.880 --> 01:13:17.600
our PC, like RPC orchestration because and I think that
1302
01:13:18.399 --> 01:13:21.640
you know, single flight mutations is one kind of flavor
1303
01:13:22.119 --> 01:13:25.920
of utilizing rpcs and orchestrating like data flow through rpcs.
1304
01:13:26.279 --> 01:13:31.760
There's other ones like routing is a big RPC orchestrator really,
1305
01:13:31.760 --> 01:13:35.039
anything that's providing life cycle based on user input, so
1306
01:13:35.359 --> 01:13:37.520
even forms or the framework itself.
1307
01:13:37.520 --> 01:13:43.880
It's it's tricky because the biggest cause of waterfalls, in
1308
01:13:43.920 --> 01:13:48.840
my opinion, in terms of co location is often those
1309
01:13:48.880 --> 01:13:52.119
two causes. There's the code splitting. We want to code
1310
01:13:52.159 --> 01:13:54.920
split at the route level generally, like you know, you
1311
01:13:54.920 --> 01:13:57.520
can do lazy components wherever, but because of the code splitting,
1312
01:13:58.279 --> 01:14:01.000
it's hard to fetch the day before you have the
1313
01:14:01.039 --> 01:14:04.439
code to pitch the data essentially, So that's what pushes
1314
01:14:04.479 --> 01:14:07.239
us to hoisting. And it's necessary because you don't want
1315
01:14:07.239 --> 01:14:08.600
to load all the JABSKO for your whole app.
1316
01:14:08.640 --> 01:14:11.960
But if you didn't, if.
1317
01:14:11.840 --> 01:14:16.199
You didn't actually do that, then the other second thing
1318
01:14:16.239 --> 01:14:20.039
you hit on the client. Is that co location of
1319
01:14:20.159 --> 01:14:24.000
UI and components can lead to waterfalls depending on how
1320
01:14:24.079 --> 01:14:27.560
the renderer handles the ACYNC in the in the rendering.
1321
01:14:27.680 --> 01:14:30.439
So like, for example, let's say every time you hit
1322
01:14:30.479 --> 01:14:32.880
a promise, you throw and it then re renders the
1323
01:14:32.880 --> 01:14:35.039
whole thing. Well, if there's a promise after that, well
1324
01:14:35.399 --> 01:14:37.199
then you're causing a waterfall, right.
1325
01:14:37.119 --> 01:14:40.560
And I'm saying that because RPC potentially brings in the
1326
01:14:40.640 --> 01:14:44.680
third cause, which is just the fact that people can
1327
01:14:45.239 --> 01:14:48.119
look at the code think that if it looks like
1328
01:14:48.199 --> 01:14:51.279
a function, then it is a function, and just write
1329
01:14:51.279 --> 01:14:54.800
the code in a way that's very inefficient and generates
1330
01:14:54.800 --> 01:14:57.479
a waterfall regardless of the framework.
1331
01:14:57.520 --> 01:15:00.239
Right right, which is which is well, I mean there's
1332
01:15:00.239 --> 01:15:04.239
two different types of waterfalls, necessary waterfalls and unnecessari stary waterfalls.
1333
01:15:04.239 --> 01:15:08.239
Necessary waterfalls can still be made unnecessary if you say,
1334
01:15:08.359 --> 01:15:10.239
move everything into a single function call and you know,
1335
01:15:10.319 --> 01:15:11.319
put them together whatever.
1336
01:15:11.560 --> 01:15:13.119
But there's a dependency.
1337
01:15:13.199 --> 01:15:15.840
But there's a dependency, right, Like there's like you need
1338
01:15:15.880 --> 01:15:18.600
to get the users to get or get the user
1339
01:15:18.640 --> 01:15:20.399
to get the posts for some reason. But if you
1340
01:15:20.399 --> 01:15:22.479
could fetch them both off the user ID, like the
1341
01:15:22.520 --> 01:15:24.640
poster is user ID and the user information off use ID,
1342
01:15:24.760 --> 01:15:27.399
then that's an unnecessary waterfall. The problem is we cause
1343
01:15:27.479 --> 01:15:31.960
unnecessary waterfalls all the time in our UI rendering. If
1344
01:15:32.079 --> 01:15:35.159
if because we go okay, well the posts go under
1345
01:15:35.199 --> 01:15:39.319
the user section, and then you you basically by by
1346
01:15:39.520 --> 01:15:41.479
using ACYNC in your component, you're basically like putting in
1347
01:15:41.479 --> 01:15:44.039
a weight in the middle and blocking. Blocking rendering sucks
1348
01:15:44.039 --> 01:15:48.399
a weights suck for rendering UI. You don't want ACYNC
1349
01:15:48.399 --> 01:15:51.880
components really it React gets away with it on the
1350
01:15:51.880 --> 01:15:54.640
server because it's on the server, and server waterfalls are
1351
01:15:54.680 --> 01:15:55.479
not as bad.
1352
01:15:55.520 --> 01:15:56.880
But I'd argue against that.
1353
01:15:56.920 --> 01:16:00.159
I'm generally speaking it's this co location of data and
1354
01:16:00.319 --> 01:16:04.199
UI that causes this blocking. The reason I'm stressing on
1355
01:16:04.239 --> 01:16:08.760
this is because it's solvable with signals, Like basically, if
1356
01:16:08.840 --> 01:16:11.880
you're doing fine green rendering, there's no reason to await
1357
01:16:12.079 --> 01:16:14.439
or block except for where the data is finally being
1358
01:16:14.520 --> 01:16:16.960
used at the end of the data chain, which means
1359
01:16:16.960 --> 01:16:21.399
that you could parallelize this data fetching for unnecessary waterfalls
1360
01:16:21.680 --> 01:16:27.479
not only for like sibling components, but also nested components.
1361
01:16:27.520 --> 01:16:30.720
Because the component aspect doesn't matter, you're not blocking to
1362
01:16:30.760 --> 01:16:34.960
re render the the you know this component, you're literally
1363
01:16:35.079 --> 01:16:37.279
just going, oh, I actually need this in this text,
1364
01:16:37.279 --> 01:16:40.800
in this div I'm going to block there and everything beside.
1365
01:16:40.840 --> 01:16:44.079
It's a sibling. You basically turn all you flatten the
1366
01:16:44.079 --> 01:16:44.600
whole tree.
1367
01:16:44.760 --> 01:16:46.640
And this is something you know, just to be clear,
1368
01:16:47.000 --> 01:16:51.880
just you do all this magic for us automatically, right,
1369
01:16:52.159 --> 01:16:53.439
It's not something.
1370
01:16:53.880 --> 01:16:56.920
I mean, this is run to time what I'm talking about.
1371
01:16:56.960 --> 01:16:58.640
The funniest thing is it's not actually magic. It's just
1372
01:16:58.680 --> 01:17:02.119
the way signals work. This is something that I kind
1373
01:17:02.159 --> 01:17:03.800
of discovered a while ago when I was doing fine
1374
01:17:03.800 --> 01:17:08.760
green rendering. That pine green rendering is actually it flattens
1375
01:17:08.760 --> 01:17:11.199
the tree. That basically what does there's no components anymore.
1376
01:17:11.239 --> 01:17:13.520
You just have a bunch of independent things. So if
1377
01:17:13.520 --> 01:17:14.119
you fly on the.
1378
01:17:14.039 --> 01:17:18.479
Tree, because signals don't care about component boundaries essentially.
1379
01:17:18.039 --> 01:17:20.039
So if you fly in the tree and talk about
1380
01:17:20.279 --> 01:17:23.479
async that way, then it's the same thing. Nothing has
1381
01:17:23.520 --> 01:17:26.119
to block unless it actually has a data dependency on itself.
1382
01:17:26.159 --> 01:17:30.199
So necessary waterfalls still walk, but things that are not
1383
01:17:30.279 --> 01:17:33.479
necessary waterfalls don't need to block. So I think this
1384
01:17:33.640 --> 01:17:36.560
is another wind that you're going to see in the
1385
01:17:36.560 --> 01:17:39.600
signal of libraries. So people haven't really been leveraging this yet,
1386
01:17:39.760 --> 01:17:43.359
but it's coming soon and we know what it looks like.
1387
01:17:43.600 --> 01:17:45.039
Right, So I'm going to jump in here because we're
1388
01:17:45.079 --> 01:17:47.800
running a little long here on time, and I have
1389
01:17:47.840 --> 01:17:50.239
a suspicion with anything that Dan gets into. We could
1390
01:17:50.239 --> 01:17:53.760
talk to for two or three hours when he gets
1391
01:17:53.800 --> 01:17:56.520
into a topic. So before we wrap up and head
1392
01:17:56.520 --> 01:18:01.399
to picks, is there any last word on our PCs?
1393
01:18:01.800 --> 01:18:02.279
In summary?
1394
01:18:02.319 --> 01:18:04.800
And all I can say is my summary is that
1395
01:18:04.840 --> 01:18:08.439
we absolutely positively need to get Ryan and Tanner on
1396
01:18:08.720 --> 01:18:12.000
to continue this conversation because we are scratching the surface.
1397
01:18:12.039 --> 01:18:12.720
It feels to me.
1398
01:18:12.920 --> 01:18:15.960
Yeah, I mean, even just what Ryan brought up about,
1399
01:18:16.000 --> 01:18:20.920
like all the ACYNC signal stuff, there's a lot that
1400
01:18:20.960 --> 01:18:21.600
we could go into.
1401
01:18:21.680 --> 01:18:24.199
Yeah, but then stuck is built on react. What does
1402
01:18:24.239 --> 01:18:25.960
that have to do with the sink signals?
1403
01:18:26.359 --> 01:18:28.439
Maybe you say something about that, let's say, let's say
1404
01:18:28.479 --> 01:18:31.600
it for later, Let's save that for later. We are
1405
01:18:31.680 --> 01:18:35.119
running along. There's a lot to talk about. But and
1406
01:18:35.199 --> 01:18:37.279
you know, hold on, you brought up a good point
1407
01:18:37.279 --> 01:18:43.800
though about the necessary waterfalls as well, Like necessary waterfalls
1408
01:18:43.800 --> 01:18:45.720
are still there and they still need to be handled,
1409
01:18:46.199 --> 01:18:48.560
And like I feel like I've been spending a lot
1410
01:18:48.560 --> 01:18:51.159
of time on that as well as like, you can
1411
01:18:51.199 --> 01:18:54.840
still make mistakes there that you can't solve with a
1412
01:18:54.880 --> 01:18:57.760
bundler or you can't solve with with signals or anything
1413
01:18:57.760 --> 01:19:00.239
like that. So but you can solve some of those
1414
01:19:00.239 --> 01:19:04.680
problems with with good API design and prefetching and and
1415
01:19:04.720 --> 01:19:06.840
you know, so, I think there's a lot more to
1416
01:19:06.960 --> 01:19:11.119
unpack there. I don't really want to. Okay, there's a
1417
01:19:11.159 --> 01:19:16.600
reason that tan Stack everything is built to be agnostic.
1418
01:19:17.119 --> 01:19:20.359
I'm a very firm believer and React and obviously it's
1419
01:19:20.399 --> 01:19:24.600
it's our most supportive framework, but it by no means perfect.
1420
01:19:24.760 --> 01:19:29.159
It's it's not, it's but it's amazing, it's great. There
1421
01:19:29.319 --> 01:19:32.800
there's pros and cons to every UI framework, but I
1422
01:19:33.119 --> 01:19:38.560
I'm very much preparing for a future where there are bigger,
1423
01:19:38.720 --> 01:19:44.520
better UI frameworks doing amazing things. And the things that
1424
01:19:44.680 --> 01:19:48.319
Ryan just teased and talking about with like signals and
1425
01:19:48.399 --> 01:19:53.479
acinc and flattening signals to to you know, around suspense
1426
01:19:53.560 --> 01:19:58.520
and things like that, that stuff's really exciting. Uh I.
1427
01:19:58.560 --> 01:20:00.399
And I'm just gonna gush a little bit right here
1428
01:20:00.439 --> 01:20:03.359
before we end and say that the things that Ryan
1429
01:20:03.600 --> 01:20:06.840
is working on with solid two point zero have made
1430
01:20:06.840 --> 01:20:10.439
me the most excited about what's technically possible with the
1431
01:20:10.560 --> 01:20:15.880
UI framework since I discovered React and discovered hooks and
1432
01:20:16.359 --> 01:20:19.079
really got into it. So hopefully it's a good teaser
1433
01:20:19.159 --> 01:20:21.000
for maybe what we can talk about next time.
1434
01:20:21.119 --> 01:20:25.920
Thank you, look, I'm here for it each and every
1435
01:20:25.920 --> 01:20:28.279
time you just say when I'll have you on the
1436
01:20:28.319 --> 01:20:28.840
show again.
1437
01:20:29.000 --> 01:20:32.760
Alrighty well, thanks to Ryan and Tanner for scratching the
1438
01:20:32.760 --> 01:20:37.479
surface on our PCs and waiting our whistle for more
1439
01:20:37.479 --> 01:20:40.199
discussion on the truly geeky stuff that we talk about.
1440
01:20:41.399 --> 01:20:43.399
With that, we'll move to picks picture, the part of
1441
01:20:43.439 --> 01:20:45.800
the show where we get to talk about anything we
1442
01:20:45.840 --> 01:20:47.840
want to talk about, could be tech related, could be
1443
01:20:47.880 --> 01:20:52.880
not tech related. We run the gamut. I will start
1444
01:20:52.880 --> 01:20:55.439
off with what I consider the high point of any
1445
01:20:55.439 --> 01:20:57.640
of our episodes, which is the dad jokes of the week.
1446
01:20:58.800 --> 01:21:00.960
So the other day I was watching a show called
1447
01:21:01.000 --> 01:21:03.760
ten Ways to Avoid a Shark attack, and I was
1448
01:21:03.800 --> 01:21:06.359
surprised that stay out of the water wasn't on the list.
1449
01:21:06.520 --> 01:21:11.279
There was actually a skit about that on YouTube where
1450
01:21:11.680 --> 01:21:15.279
they do a parody of a horror movie when there's
1451
01:21:15.359 --> 01:21:18.399
the shark in the pool, and everybody's like, oh my god,
1452
01:21:18.439 --> 01:21:19.560
there's a shark in the pool.
1453
01:21:19.600 --> 01:21:20.359
What can we do in this?
1454
01:21:20.479 --> 01:21:22.239
The one guy keeps on saying.
1455
01:21:22.479 --> 01:21:25.359
Just don't go into the pool, right right.
1456
01:21:25.439 --> 01:21:29.880
So yeah, my drum joke here is not working. And
1457
01:21:29.920 --> 01:21:32.600
I'm really bummed because that adds all the impact. So
1458
01:21:32.760 --> 01:21:35.760
I'm gonna have to sue a riverside for that one.
1459
01:21:36.319 --> 01:21:39.640
So my wife looked at my feet this morning and said, honey,
1460
01:21:39.640 --> 01:21:41.720
your socks don't match. And I said, that's funny. I
1461
01:21:41.720 --> 01:21:43.399
have another pair just like them in the drawer. But
1462
01:21:43.520 --> 01:21:47.760
it boom. And then finally, in a surprising announcement, Head
1463
01:21:47.800 --> 01:21:52.279
Shoulders have decided to discontinue their popular anti dandruff shampoo line.
1464
01:21:52.359 --> 01:21:55.359
The decision left many people scratching their heads. I expected
1465
01:21:55.840 --> 01:21:57.880
not that I need that, as you can tell by
1466
01:21:57.920 --> 01:22:01.159
the video. So those are the dad jokes of the week. Dan,
1467
01:22:01.399 --> 01:22:02.600
you got any picks for us?
1468
01:22:03.079 --> 01:22:05.479
Yeah? So two funny things.
1469
01:22:06.000 --> 01:22:08.920
First of all, Avishai Shalom, we've had on this show
1470
01:22:09.079 --> 01:22:13.039
a while back, made an interesting observation on X and
1471
01:22:13.079 --> 01:22:15.920
I literally quote him because he just wrote it very well.
1472
01:22:16.319 --> 01:22:19.720
He was talking about the fact that will Ai destroy
1473
01:22:19.800 --> 01:22:24.960
the Worldwide Web because the bit it's destroying the web's
1474
01:22:25.039 --> 01:22:29.399
business model, and he says it's actually worse. NLM's marked
1475
01:22:29.399 --> 01:22:32.720
the end of open networks because the cost of producing
1476
01:22:32.880 --> 01:22:37.399
junk and malicious content is now near zero. We already
1477
01:22:37.479 --> 01:22:41.239
see this in LinkedIn, Facebook, et cetera, but more alarming
1478
01:22:41.359 --> 01:22:46.239
in GitHub and NPM. And it's a very interesting observation,
1479
01:22:46.359 --> 01:22:49.680
I think, And so that would be my first pick,
1480
01:22:49.720 --> 01:22:52.680
that observation. And the second one is this funny story
1481
01:22:52.680 --> 01:22:56.039
that just came out about the fact that the UK
1482
01:22:56.239 --> 01:22:59.840
government is trying to sue four Chan. Turns out that
1483
01:22:59.880 --> 01:23:04.079
the the UK passed the law that requires age verification
1484
01:23:04.760 --> 01:23:11.000
before you access potentially offensive content, and four Chan, being
1485
01:23:11.039 --> 01:23:16.000
an American company, is not complying with the UK laws,
1486
01:23:16.319 --> 01:23:21.279
so they're actually trying to force them to comply by
1487
01:23:21.520 --> 01:23:26.039
they sent them a threatening email and they basically responded
1488
01:23:26.159 --> 01:23:30.359
with First Amendment bitches. And it will be interesting to
1489
01:23:30.399 --> 01:23:32.880
see where this goes. So yeah, that would be my
1490
01:23:33.000 --> 01:23:38.039
second pick. And I think you can tell which side
1491
01:23:38.079 --> 01:23:41.760
them on in this argument, or put it this way,
1492
01:23:41.920 --> 01:23:44.479
The worst thing that has ever ever happened to the web,
1493
01:23:44.520 --> 01:23:46.399
I think is GDPR.
1494
01:23:46.960 --> 01:23:47.359
Yes, and.
1495
01:23:50.079 --> 01:23:51.600
Yeah, we don't need any more of that.
1496
01:23:52.439 --> 01:23:55.600
So yeah, those would be my two picks for today.
1497
01:23:55.720 --> 01:23:57.720
All right, Tanner, you got any picks for us?
1498
01:23:57.920 --> 01:24:01.800
Picks? Picks them of these pics? Do these picks needed?
1499
01:24:02.039 --> 01:24:06.640
Is random the room? The randomer the better, randomer the better.
1500
01:24:07.000 --> 01:24:09.880
Okay, why you think about it, We'll go to Ryan.
1501
01:24:09.960 --> 01:24:11.079
See if Ryan anything.
1502
01:24:11.960 --> 01:24:14.880
Ryan, I'm just gonna think here because I've been so busy.
1503
01:24:15.039 --> 01:24:17.279
If you guys don't know, I have a little baby
1504
01:24:17.439 --> 01:24:20.760
at home, so I have that to your pick. Yeah,
1505
01:24:20.800 --> 01:24:24.119
I mean, I mean, honestly, I don't get to watch
1506
01:24:24.199 --> 01:24:26.199
or check out nearly as much as I want to
1507
01:24:26.479 --> 01:24:28.920
that and like kids shows. I recently watched what it
1508
01:24:28.960 --> 01:24:30.600
was like K Pop Demon Hunters.
1509
01:24:31.319 --> 01:24:32.920
I've heard real good things about that one.
1510
01:24:32.960 --> 01:24:35.479
Yeah, you know, I mean if I mean, people are
1511
01:24:35.479 --> 01:24:38.000
gonna disagree with me, but it gave me like it's
1512
01:24:38.039 --> 01:24:42.279
got almost like Sailor Moon vibes, but like some big production,
1513
01:24:43.720 --> 01:24:45.159
you know, thang it.
1514
01:24:45.159 --> 01:24:46.640
It was fun, the kids liked it.
1515
01:24:47.600 --> 01:24:49.920
Since you mentioned the show, and to give Tennor a
1516
01:24:50.000 --> 01:24:52.119
little bit more time, I have to say that I
1517
01:24:52.319 --> 01:24:57.000
was really disappointed with the second season of San I mean,
1518
01:24:57.199 --> 01:25:00.920
they had an entire episode which was literally funeral. I
1519
01:25:00.960 --> 01:25:02.560
mean what the half.
1520
01:25:02.640 --> 01:25:05.159
I haven't watched that one, so I can't.
1521
01:25:05.640 --> 01:25:07.359
Oh, I know, I know what else I want to
1522
01:25:07.359 --> 01:25:09.319
say without giving away too much. I actually enjoyed the
1523
01:25:09.399 --> 01:25:11.960
ending of season three of Squid game station to have
1524
01:25:12.000 --> 01:25:15.359
split it, but oh really, but I like the second
1525
01:25:15.399 --> 01:25:18.479
third season together. It ended in a I like the
1526
01:25:18.479 --> 01:25:20.800
way it ended, So maybe I'm made me minority. But
1527
01:25:20.840 --> 01:25:23.560
I actually if if if you're willing to watch the
1528
01:25:23.600 --> 01:25:26.000
second season, that you should finish it with the third season.
1529
01:25:26.279 --> 01:25:28.479
Well, yeah, is really into that one, and he was
1530
01:25:28.520 --> 01:25:30.359
explaining the plot to me. I haven't watched the NAVA,
1531
01:25:30.399 --> 01:25:32.640
but he's explaining to me, and I mean, it sounded
1532
01:25:33.039 --> 01:25:35.079
the first season is just creeped me out. It was
1533
01:25:35.119 --> 01:25:36.880
more of a Hunger Games type vibe and it just
1534
01:25:37.000 --> 01:25:39.720
sort of creeped me out. But he was explaining what
1535
01:25:39.880 --> 01:25:41.720
was going on in the second third seasons to me,
1536
01:25:41.800 --> 01:25:44.279
and that's that's pretty intriguing the way they're doing it
1537
01:25:44.680 --> 01:25:45.000
right now.
1538
01:25:45.119 --> 01:25:46.880
Thank you word for it, as long as you don't
1539
01:25:46.880 --> 01:25:49.479
tell me that you enjoyed the eighth season of Game
1540
01:25:49.479 --> 01:25:50.039
of Thrones.
1541
01:25:52.000 --> 01:25:54.640
No, no, that was that was not my favorite. All right, Tanner,
1542
01:25:54.680 --> 01:25:55.439
we gave you some time.
1543
01:25:55.479 --> 01:25:58.119
What do you got. I mean, I like Ryan I,
1544
01:25:58.199 --> 01:26:02.760
so I don't consume a whole lot of of what's
1545
01:26:02.800 --> 01:26:06.920
out there. I'm I'm more of a builder, but there
1546
01:26:07.159 --> 01:26:09.520
there are a few things that I do I do enjoy.
1547
01:26:09.600 --> 01:26:14.359
So I'm overly hyped for the new season of Stranger
1548
01:26:14.399 --> 01:26:17.800
Things coming out, and so we've been rewatching all of
1549
01:26:17.840 --> 01:26:20.279
the seasons before it. So that means that I've seen
1550
01:26:20.279 --> 01:26:23.479
the fourth the first season four times, the second season
1551
01:26:23.520 --> 01:26:27.239
three one, and so forth, and we're watching the fourth
1552
01:26:27.279 --> 01:26:29.800
season four the second time now, and then we're going
1553
01:26:29.840 --> 01:26:31.840
to anxiously await number five. Yeah.
1554
01:26:32.079 --> 01:26:35.359
That's an interesting argument that I had with aj about
1555
01:26:36.920 --> 01:26:41.199
fantasy book series that tend to come, you know, not
1556
01:26:41.279 --> 01:26:44.600
yet finished, and then the next book comes three years
1557
01:26:44.640 --> 01:26:47.560
after the previous book, and you don't remember anything. And
1558
01:26:47.640 --> 01:26:50.520
I never have it in me to reread that those
1559
01:26:50.600 --> 01:26:53.640
previous books. So you're basically you do have it in
1560
01:26:53.680 --> 01:26:55.399
you to rewatch the entire series.
1561
01:26:55.439 --> 01:26:58.800
They were they were so good, and you know, Stranger
1562
01:26:58.880 --> 01:27:03.479
Things connoisseurs will tell you, well, this season was worse
1563
01:27:03.520 --> 01:27:07.399
and this season was terrible, and but like going back
1564
01:27:07.439 --> 01:27:10.439
and watching them, I mean, I'm it's been a long
1565
01:27:10.439 --> 01:27:12.600
time since the first one came out, so like, I
1566
01:27:12.600 --> 01:27:15.359
am very much more adult now than I was then
1567
01:27:15.720 --> 01:27:20.039
watching them, and just the the acting from these kids
1568
01:27:20.319 --> 01:27:25.399
is just incredible. It really is so good. And and
1569
01:27:25.439 --> 01:27:28.119
the writing for for how quick they were taking out
1570
01:27:28.159 --> 01:27:31.439
the first couple of seasons, like the writing in some places,
1571
01:27:31.479 --> 01:27:33.239
I was like, okay, like that could have been better,
1572
01:27:33.239 --> 01:27:37.399
But for the most part, we're just spoiled with great content,
1573
01:27:37.560 --> 01:27:43.039
like what a fun story, a great story. And yeah,
1574
01:27:43.159 --> 01:27:45.119
I was just telling my wife. Season four got a
1575
01:27:45.159 --> 01:27:48.159
little dicey because it started feeling really evil, and I
1576
01:27:48.199 --> 01:27:49.399
was like, well, I don't know if I want to
1577
01:27:49.439 --> 01:27:51.039
take part in this anymore. And then all of a
1578
01:27:51.039 --> 01:27:53.920
sudden it went super sci fi and I was like, okay,
1579
01:27:53.960 --> 01:27:59.039
this is awesome. So yeah, we've been watching Stranger Things
1580
01:27:59.079 --> 01:28:02.880
and that's about the only like one episode at night
1581
01:28:02.960 --> 01:28:06.880
and then I'm asleep, so that's about the amount of
1582
01:28:06.880 --> 01:28:08.119
time that I have to consume.
1583
01:28:08.399 --> 01:28:11.600
How old are your kids, if I might ask, I.
1584
01:28:11.600 --> 01:28:15.720
Have a a seven year old, a four year old,
1585
01:28:16.039 --> 01:28:20.520
and a almost two year old, So well, I'm not
1586
01:28:21.119 --> 01:28:25.960
they're not watching Stranger Things right now? For them? Is
1587
01:28:26.119 --> 01:28:28.760
I just really I just introduced them to spy kids
1588
01:28:30.119 --> 01:28:33.600
and they are like, this is the coolest series ever made,
1589
01:28:34.319 --> 01:28:37.239
So you know, they're they're living in a different world
1590
01:28:37.319 --> 01:28:41.359
right now. That's just as cool, but way more child friendly.
1591
01:28:42.079 --> 01:28:44.680
No, I was asking for the perspective of your free
1592
01:28:44.720 --> 01:28:48.119
time because, like Ryan said, then you have little children
1593
01:28:48.159 --> 01:28:48.520
at home.
1594
01:28:48.880 --> 01:28:51.880
Yeah, we both have little children, and I know that
1595
01:28:52.159 --> 01:28:56.039
I know from talking to Fran that they consume, happily
1596
01:28:56.359 --> 01:29:00.520
consume a lot of our time. So yeah, I it's
1597
01:29:00.560 --> 01:29:03.840
basically at night for maybe an hour that you know,
1598
01:29:03.880 --> 01:29:06.640
we get to indulge in something.
1599
01:29:06.760 --> 01:29:10.000
So all I can say though is from watching from
1600
01:29:10.039 --> 01:29:13.399
the other side as it were enjoyed while it lasts.
1601
01:29:13.520 --> 01:29:15.159
Yes, oh yeah for sure.
1602
01:29:15.279 --> 01:29:18.680
Yeah, mine are twenty five, about to get married twenty
1603
01:29:18.720 --> 01:29:23.439
two and Congratulateen, and so yeah, we have a lot
1604
01:29:23.479 --> 01:29:26.239
more a little more free time. But yeah, I missed
1605
01:29:26.279 --> 01:29:28.119
some of those. I'm looking forward to grandkids and be
1606
01:29:28.199 --> 01:29:30.079
able to have the kids into then say here you go,
1607
01:29:31.279 --> 01:29:31.560
you know.
1608
01:29:31.680 --> 01:29:35.000
Yeah, well my baby goes twenty three years old working
1609
01:29:35.039 --> 01:29:35.479
in tech.
1610
01:29:36.720 --> 01:29:37.199
Very cool.
1611
01:29:37.800 --> 01:29:40.159
Yeah all right, So with that, we're going to wrap
1612
01:29:40.199 --> 01:29:42.239
this up and hopefully we'll have these two backing in
1613
01:29:42.319 --> 01:29:45.840
to continue our discussion in the meantime. Thanks for watching
1614
01:29:45.880 --> 01:29:48.159
slash listening, and we'll talk at you next time.
1615
01:29:48.279 --> 01:29:50.880
Bye.
1
00:00:05.240 --> 00:00:09.839
Hello, everybody, Welcome to another exciting ever episode of javascripts Jabber.
2
00:00:09.880 --> 00:00:11.880
I am Steve Edwards, the host with the face for
3
00:00:12.000 --> 00:00:13.800
radio as you can see in the voice for being
4
00:00:13.800 --> 00:00:17.519
a mine, but I'm still your host with me Today
5
00:00:17.600 --> 00:00:20.000
on the panel, we have mister Dan Shapiro coming live
6
00:00:20.039 --> 00:00:22.359
from tell Abev, Israel. How you doing, Dan, But well.
7
00:00:22.239 --> 00:00:24.839
You know it's hot here as surprise, surprise.
8
00:00:25.559 --> 00:00:27.719
Yeah, we're going back and forth here. It was pretty
9
00:00:27.719 --> 00:00:29.600
warm last couple weeks and now it's a little cool
10
00:00:29.640 --> 00:00:32.600
and cloudy and it's gonna be pretty mellow, so pretty nice.
11
00:00:32.759 --> 00:00:35.039
As we're getting to the end of August, I'm going
12
00:00:35.079 --> 00:00:39.240
to let Dan introduce our special returning guests, So go for.
13
00:00:39.240 --> 00:00:39.560
It, Dan.
14
00:00:39.920 --> 00:00:43.719
Yeah. So I'm really excited about today's guests. We have
15
00:00:43.799 --> 00:00:47.560
two of them, which means it's double the pleasure, and
16
00:00:47.640 --> 00:00:50.359
they are both a living testament to the fact that
17
00:00:50.679 --> 00:00:53.799
you don't need to work at Google or at Meta
18
00:00:53.960 --> 00:00:56.359
or at some other fang in order to make a
19
00:00:56.479 --> 00:01:01.119
huge impact on web development. So we have Ryan Carneato
20
00:01:01.719 --> 00:01:05.040
and we have Tanner Lindsley. Hi, guys, want to introduce
21
00:01:05.079 --> 00:01:08.359
yourselves in case somebody somehow doesn't know who you.
22
00:01:08.319 --> 00:01:12.560
Are Oh sorry, I hit the plauser. Okay, I got
23
00:01:12.599 --> 00:01:15.319
to get that crowd to control themselves. Lots of fun.
24
00:01:15.760 --> 00:01:20.200
Yeah, I'm Brian Carneado, probably most known for creating solid
25
00:01:20.239 --> 00:01:24.400
Jazz and my work on Signals CEO of Signals and Tanner.
26
00:01:25.079 --> 00:01:26.400
I'm the tan Stack guy.
27
00:01:26.680 --> 00:01:29.480
And for those who don't happen to know, Tanstack is
28
00:01:29.560 --> 00:01:32.519
also where react query came from.
29
00:01:32.560 --> 00:01:37.280
Now tanstack query right, React Query I even I still
30
00:01:37.319 --> 00:01:38.760
call it that, which is fine.
31
00:01:38.840 --> 00:01:42.879
And also lots of other great tools. You've recently introduced
32
00:01:42.879 --> 00:01:43.319
a couple.
33
00:01:43.519 --> 00:01:48.560
Yeah, we we have just a couple. We're working on
34
00:01:48.599 --> 00:01:52.879
a new framework inspired by solid Start called tan sax Start.
35
00:01:53.920 --> 00:01:57.959
We have a router. We have a new library called pacer,
36
00:01:58.120 --> 00:02:03.599
which is about like debound throttling, ate leming stuff. We
37
00:02:03.640 --> 00:02:09.719
have the controversial name tan stack dB, which is a
38
00:02:09.800 --> 00:02:13.840
reactive client store. I mean it's a database, but it's
39
00:02:13.879 --> 00:02:15.639
only for like the client on the front end. It's
40
00:02:15.639 --> 00:02:20.520
pretty sweet, guys, except that it isn't right. Yeah, it's
41
00:02:21.319 --> 00:02:24.319
it's an awesome library. That's all you need to know. Uh.
42
00:02:25.080 --> 00:02:28.879
And we've got like table and form as well virtual
43
00:02:29.879 --> 00:02:33.120
h We've got a couple. We're even working on something
44
00:02:33.159 --> 00:02:36.319
called tan Sak dev tools right now, which is oh
45
00:02:36.400 --> 00:02:37.520
yeah about that.
46
00:02:37.599 --> 00:02:39.879
We will have to bring either you or somebody else
47
00:02:39.919 --> 00:02:41.960
on the team on to talk about that when you're
48
00:02:41.960 --> 00:02:44.759
different than you guys already h and I have to
49
00:02:44.800 --> 00:02:51.520
also mention create tense ten stack start or whatever Jack
50
00:02:52.479 --> 00:02:53.199
these days.
51
00:02:53.280 --> 00:02:55.800
Whatever we're going gonna call it, and it might even
52
00:02:55.840 --> 00:02:58.919
just be called create tan Stacking like that.
53
00:02:58.840 --> 00:03:01.159
For those of you don't know that is. We actually
54
00:03:01.280 --> 00:03:03.680
had Jack Harrington on the show to talk about it.
55
00:03:03.680 --> 00:03:07.879
It's an awesome replacement for create react at least.
56
00:03:08.280 --> 00:03:10.159
Yeah, we have some fun plans for it.
57
00:03:10.280 --> 00:03:13.240
So it's Tanstack Ranger. I'm looking at a last.
58
00:03:13.560 --> 00:03:19.439
Ranger is kind of a throwback to my old open
59
00:03:19.439 --> 00:03:21.960
source days. It's it's I needed a library to do
60
00:03:22.159 --> 00:03:28.199
multi range inputs, so like sliders with multiple handles. I
61
00:03:28.639 --> 00:03:32.560
made a headless version of it. I called it Ranger,
62
00:03:33.560 --> 00:03:34.360
which is kind of fun.
63
00:03:34.639 --> 00:03:37.759
See I'm thinking like Park Ranger and uh, you know
64
00:03:37.840 --> 00:03:40.759
Jellystone Park and I remember that.
65
00:03:42.000 --> 00:03:47.599
Yeah, it's probably it's it's the most niche library that
66
00:03:47.639 --> 00:03:50.639
we have, which it's cool. I still use it every
67
00:03:50.639 --> 00:03:51.120
now and then.
68
00:03:51.879 --> 00:03:54.120
And one more thing about you, Tanner, correct me if
69
00:03:54.159 --> 00:03:58.080
I'm wrong, but you're now you've transitioned to work full
70
00:03:58.159 --> 00:04:00.159
time on your open source staf.
71
00:04:00.319 --> 00:04:02.879
Right, yeah, about a year and a half ago.
72
00:04:03.039 --> 00:04:08.039
That is awesome. So basically you're the guy not making
73
00:04:08.039 --> 00:04:09.800
a living, so the rest of us can.
74
00:04:10.039 --> 00:04:15.719
I mean as of nine months ago, I'm making a
75
00:04:15.759 --> 00:04:16.439
good living now.
76
00:04:17.079 --> 00:04:19.399
So yeah, so what is your business model for that?
77
00:04:19.439 --> 00:04:25.480
Then? Well, it's it's different than most others, I think,
78
00:04:25.519 --> 00:04:31.680
so I abhor VC around oss. I've done venture capital
79
00:04:31.720 --> 00:04:37.040
for my last company, and I've also bootstrapped plenty of things.
80
00:04:37.839 --> 00:04:39.600
I didn't want to do that for tanse Dec. So
81
00:04:40.240 --> 00:04:45.199
Tensex basically run like a media company right now, as
82
00:04:45.240 --> 00:04:51.040
like a business side of things, so marketing, advertising, partnership,
83
00:04:51.160 --> 00:04:55.439
brand deals and the like. And that's how tanse Dec
84
00:04:56.000 --> 00:05:01.720
is making money and paying both me and also now
85
00:05:01.800 --> 00:05:05.600
contributing a lot towards contributors as well, and that's just
86
00:05:05.600 --> 00:05:07.959
going to grow over time hopefully.
87
00:05:08.000 --> 00:05:12.319
Does that mean running ads within your website, within your
88
00:05:13.040 --> 00:05:14.680
products or something else?
89
00:05:15.360 --> 00:05:18.759
Yeah, So tan stack dot com is the revenue generator
90
00:05:19.480 --> 00:05:25.160
and the libraries are just guests on the tan stack
91
00:05:25.199 --> 00:05:28.879
dot com show every day.
92
00:05:28.519 --> 00:05:32.279
That's interesting. Yeah, I'm really happy that it's working for you.
93
00:05:33.000 --> 00:05:36.439
Yeah, it's working so far, so we'll we'll see. I
94
00:05:36.439 --> 00:05:40.839
don't know if it's scalable or not, but it works
95
00:05:40.879 --> 00:05:43.240
for me, and I think that's that's good enough for now.
96
00:05:43.319 --> 00:05:46.680
And how about you, Ryan, how are things with you?
97
00:05:46.720 --> 00:05:47.160
Pretty good?
98
00:05:47.839 --> 00:05:52.279
I've been at Century now for almost a year, so okay, Yeah,
99
00:05:52.399 --> 00:05:54.959
like this week coming up marks a year Century So
100
00:05:55.800 --> 00:06:00.360
they've been great, been able to obviously support my U,
101
00:06:00.879 --> 00:06:02.240
R and D. I've been doing a lot this year
102
00:06:02.240 --> 00:06:05.759
because I've been working a lot of new areas kind
103
00:06:05.800 --> 00:06:10.720
of for upcoming releases of Solid and and they've been
104
00:06:10.720 --> 00:06:12.879
supporting lots of other ways. I've been getting closer with
105
00:06:12.920 --> 00:06:14.319
the syntax FM guys.
106
00:06:15.160 --> 00:06:16.600
I was gonna ask if you worked with them.
107
00:06:17.079 --> 00:06:20.040
Yeah, So we've been talking about how to up my
108
00:06:20.079 --> 00:06:24.199
game on video content and different kinds of media stuff
109
00:06:24.319 --> 00:06:25.399
like better promotion.
110
00:06:25.759 --> 00:06:28.720
So I'm guessing they told you you need to make
111
00:06:28.759 --> 00:06:29.879
longer videos.
112
00:06:30.480 --> 00:06:33.759
Yeah, that's funny, No, they were.
113
00:06:34.120 --> 00:06:36.199
Everyone's been really stoked on those shorter videos that I've
114
00:06:36.199 --> 00:06:38.399
been doing recently. They said they were like a little crunched,
115
00:06:38.800 --> 00:06:42.560
could do some more production value, but generally speaking, I
116
00:06:42.639 --> 00:06:46.439
usually stream for like five hours ish you know, maybe
117
00:06:46.439 --> 00:06:49.920
every other Friday or so. And I started in the
118
00:06:49.959 --> 00:06:53.120
last couple of months doing like ten minute videos, and
119
00:06:53.639 --> 00:06:55.319
for me, doing ten minute videos very hard.
120
00:06:55.319 --> 00:06:56.079
It's condensed.
121
00:06:56.120 --> 00:07:00.959
It's like because I picked really deep topics, but I
122
00:07:01.040 --> 00:07:03.079
just needed a place to point people too. When people
123
00:07:03.079 --> 00:07:05.600
are like, you know, signals, blah blah blah blah blah,
124
00:07:05.600 --> 00:07:07.360
you know, like complains. You know, I'm a React developer.
125
00:07:07.399 --> 00:07:09.120
I don't get why they important. It's just like, okay, well,
126
00:07:09.199 --> 00:07:11.759
can I make an FAQ basically as a video. And
127
00:07:12.199 --> 00:07:15.120
that's sort of what I've been trying to do. Find
128
00:07:15.160 --> 00:07:18.079
content that's sure enough that people will not like bulk
129
00:07:18.319 --> 00:07:22.360
looking at the whole length of the video, but then
130
00:07:22.439 --> 00:07:26.600
still get a lot of unique content in there. It's
131
00:07:26.639 --> 00:07:29.879
difficult because my expertise is I said, very very deep.
132
00:07:30.720 --> 00:07:33.759
You don't really find content like I do in most
133
00:07:34.040 --> 00:07:36.240
video content. Like you guys sometimes get really deep on
134
00:07:36.279 --> 00:07:38.519
your podcast, which is why I love this podcast. But
135
00:07:38.600 --> 00:07:42.079
a lot of video content isn't the same sort of thing.
136
00:07:42.319 --> 00:07:44.199
You know, it's either like how do you do this?
137
00:07:45.000 --> 00:07:49.720
Or it's like the most beginner intro level of stuff.
138
00:07:49.759 --> 00:07:52.759
So being able to ask the whys, I think is
139
00:07:52.800 --> 00:07:55.120
really really important and like looking at the design stuff.
140
00:07:55.160 --> 00:07:57.480
So I'm going to try and bridge that gap, you know,
141
00:07:57.519 --> 00:08:00.920
maybe pick smaller topics that I can actually talk about,
142
00:08:00.959 --> 00:08:02.879
you know, in seven to ten minutes.
143
00:08:03.439 --> 00:08:06.160
So you kind of remind me of that. I think
144
00:08:06.199 --> 00:08:08.759
it's Mark Twain who said I didn't have the time
145
00:08:08.800 --> 00:08:11.800
to write your long letters short letters, so I wrote
146
00:08:11.839 --> 00:08:15.199
you a long one. So yeah, it's exactly much much
147
00:08:15.199 --> 00:08:19.800
more challenging to create short and concise and to the
148
00:08:19.879 --> 00:08:20.759
point content.
149
00:08:21.319 --> 00:08:23.959
Yeah, especially if you spend all your time like like
150
00:08:24.199 --> 00:08:27.759
really like like just kind of exploring ideas and stuff,
151
00:08:27.800 --> 00:08:30.279
you know, and taking stuff which way to actually come
152
00:08:30.360 --> 00:08:32.879
up to a consolidated messages way more work. I can
153
00:08:32.879 --> 00:08:35.120
stream for five hours, but then I'm like mostly done.
154
00:08:36.080 --> 00:08:38.080
The video is going to take me at least two
155
00:08:38.200 --> 00:08:40.000
or three days.
156
00:08:39.720 --> 00:08:43.559
You know, that's for sure. Well, let's put it this way.
157
00:08:43.600 --> 00:08:45.519
I think that once you get the hang of it,
158
00:08:45.679 --> 00:08:48.759
you'll be able to do it much more effectively. Maybe
159
00:08:48.759 --> 00:08:50.840
you should also consult about it with THEO.
160
00:08:51.320 --> 00:08:51.519
Yeah.
161
00:08:51.600 --> 00:08:56.279
Yeah, he's been waiting for me to like level up that.
162
00:08:56.559 --> 00:08:58.200
He was like, yeah, I just keep on doing what
163
00:08:58.240 --> 00:08:59.960
you're doing, but when it's time come see me you know,
164
00:09:00.240 --> 00:09:02.799
like better gear, better stuff, you know.
165
00:09:03.080 --> 00:09:06.399
So yeah, yeah, I did one video for for you
166
00:09:06.639 --> 00:09:11.759
Mastery a couple of years ago, And the amount of
167
00:09:11.799 --> 00:09:14.399
work it takes to get to just to put together
168
00:09:15.159 --> 00:09:18.519
simple videos is crazy. Whether it's recording, I would assume
169
00:09:18.519 --> 00:09:20.879
that once you get your setup in place, you know,
170
00:09:20.960 --> 00:09:23.799
your your software and your different artwork components and your
171
00:09:23.840 --> 00:09:25.519
speakers and all that stuff, and you know what you're doing,
172
00:09:25.559 --> 00:09:29.000
it's probably a lot quicker. But that's that's got to
173
00:09:29.039 --> 00:09:31.120
be a learning curve just in getting set up to
174
00:09:31.159 --> 00:09:32.879
do video production like that.
175
00:09:33.440 --> 00:09:36.840
Yeah, and I like editing stuff in I'm a big
176
00:09:36.879 --> 00:09:39.960
fan of fireship videos and even my articles are like that.
177
00:09:40.000 --> 00:09:42.759
I've always done a lot of meme pictures and like
178
00:09:42.759 --> 00:09:45.879
like images to back up what I'm saying, Yes, can
179
00:09:45.919 --> 00:09:47.679
I keep it going? Even my conference talks are like
180
00:09:47.720 --> 00:09:50.320
that too. So I find the video editing actuallyising a
181
00:09:50.320 --> 00:09:52.039
long time because I need to find just the perfect
182
00:09:52.200 --> 00:09:57.000
clip or the perfect like image to kind of overlay
183
00:09:57.600 --> 00:10:01.000
the different parts. So like it's like it's almost on
184
00:10:01.039 --> 00:10:04.519
like a twenty second cadence, so like it's you know,
185
00:10:04.639 --> 00:10:05.679
twenty minute video.
186
00:10:05.960 --> 00:10:07.159
You know, that's a lot of clips.
187
00:10:07.600 --> 00:10:09.399
Well, just let AI do it for you.
188
00:10:10.240 --> 00:10:11.799
Well, you know, I have the same struggle with always
189
00:10:11.840 --> 00:10:14.120
trying to find a perfect dad joke to publish on
190
00:10:14.159 --> 00:10:15.960
a daily basis and to throw in here and there
191
00:10:16.000 --> 00:10:18.279
so I can somewhat they all perfect.
192
00:10:18.279 --> 00:10:19.639
Stage, they're all perfect.
193
00:10:20.120 --> 00:10:21.840
Oh boy, I got to tell you some stories about
194
00:10:21.840 --> 00:10:24.919
how they're not always, but that's a topic for another time.
195
00:10:25.200 --> 00:10:28.039
Yeah, I think we need to finally get to the
196
00:10:28.320 --> 00:10:30.919
to the crux to the main issue.
197
00:10:31.080 --> 00:10:33.080
We had a topic for today, any topic that we're
198
00:10:33.120 --> 00:10:34.639
here to discuss, gotcha.
199
00:10:34.720 --> 00:10:39.320
So again, I'll give a brief background. A while back,
200
00:10:39.399 --> 00:10:43.519
I had this idea of le let's go even further back.
201
00:10:43.639 --> 00:10:49.000
I started noticing a certain pattern that was occurring in
202
00:10:49.080 --> 00:10:53.440
a lot of frameworks, especially as they were becoming meta frameworks,
203
00:10:53.840 --> 00:10:56.480
and that's kind of and I termed it to come
204
00:10:56.480 --> 00:10:59.919
back of RPC, and we'll talk about what RPC is
205
00:11:00.360 --> 00:11:04.799
and why it's making this comeback now. But when I
206
00:11:04.960 --> 00:11:07.559
noticed that, it occurred to me that this could be
207
00:11:07.559 --> 00:11:11.039
an interesting topic for a conference talk, which I created
208
00:11:11.080 --> 00:11:15.120
and already gave once at JS Heroes in Romania. But
209
00:11:15.200 --> 00:11:17.679
I reached out to a lot of my friends, people
210
00:11:17.799 --> 00:11:24.240
like Ryan, like Tanner, like Rich Harris and others, and
211
00:11:24.320 --> 00:11:28.720
started in Jack Harrington, whom we mentioned, and started talking
212
00:11:28.759 --> 00:11:33.080
with them about this whole thing, and I realized that
213
00:11:33.120 --> 00:11:36.840
a lot of them had very different viewpoints about what
214
00:11:36.879 --> 00:11:40.559
our PC is, how it should or should not be used,
215
00:11:41.159 --> 00:11:46.559
why it's interesting or maybe not. And what this ended
216
00:11:46.679 --> 00:11:50.799
up is this conversation here. I basically asked both Ryan
217
00:11:50.879 --> 00:11:53.519
and Tanner if they'd like to come on the show
218
00:11:53.960 --> 00:11:57.639
and talk about this, so, you know, take it away, guys.
219
00:11:57.919 --> 00:12:02.440
Yeah, I start because I feel like this starts with
220
00:12:03.240 --> 00:12:06.759
stuff that I was doing. But to be fair, this
221
00:12:06.799 --> 00:12:08.879
is stuff that Tenor definitely relates to right off the bat,
222
00:12:08.919 --> 00:12:11.360
because the first thing you hit when you're writing a
223
00:12:11.360 --> 00:12:14.759
meta framework, like the most obvious thing is actually meta
224
00:12:14.759 --> 00:12:18.759
frameworks are centered around routing, right and the router And
225
00:12:19.679 --> 00:12:21.360
I know this has nothing to do with RPC right
226
00:12:21.399 --> 00:12:22.320
off the bat, but like.
227
00:12:23.000 --> 00:12:26.279
Maybe we should define our PC before we dive into it.
228
00:12:26.559 --> 00:12:31.879
Yeah, okay, sure, A remote procedure call basically this idea
229
00:12:31.879 --> 00:12:34.639
that you can in different environments call a function from
230
00:12:34.679 --> 00:12:35.559
the other environment.
231
00:12:36.039 --> 00:12:38.320
Because I thought it was really popular comedy for a moment,
232
00:12:38.399 --> 00:12:38.960
glad read.
233
00:12:40.519 --> 00:12:44.240
I like to use a slightly different definition the way
234
00:12:44.240 --> 00:12:49.600
that I like to define it is basically as a
235
00:12:49.639 --> 00:12:55.120
method for invoking a service or obtaining data from another process,
236
00:12:55.559 --> 00:12:59.679
even on another computer across the network, using a function
237
00:12:59.799 --> 00:13:04.679
call paradigm. Are you okay with this definition? Yes, So
238
00:13:04.720 --> 00:13:07.440
it's basically it looks like a function call. It feels
239
00:13:07.519 --> 00:13:10.600
like a function call. You. It's as easy to use
240
00:13:10.639 --> 00:13:13.360
as a natural to use as a function call, but
241
00:13:13.600 --> 00:13:17.320
instead of just actually being a function call, it translates
242
00:13:17.360 --> 00:13:18.960
to an operation across the net.
243
00:13:19.120 --> 00:13:19.360
Yeah.
244
00:13:19.799 --> 00:13:22.039
The funniest thing is, like my first introduction to rpcs
245
00:13:22.080 --> 00:13:24.759
didn't feel as easy or natural to use as function calls.
246
00:13:25.200 --> 00:13:26.360
I was using a.
247
00:13:26.519 --> 00:13:31.799
Like soap in Microsoft stuff back in the early two thousands,
248
00:13:31.879 --> 00:13:34.840
And if anyone's us that it's like all XML based
249
00:13:34.919 --> 00:13:38.960
and they call they get categorized under RPC. But that
250
00:13:39.080 --> 00:13:42.679
like in my head when someone says RPC to me, traditionally,
251
00:13:42.720 --> 00:13:44.600
that's what I thought of. I thought of these like
252
00:13:45.120 --> 00:13:49.960
XML end points from like Microsoft Server from like two
253
00:13:50.039 --> 00:13:52.799
thousand and two.
254
00:13:52.879 --> 00:13:53.399
Memories.
255
00:13:53.720 --> 00:13:56.159
Yeah, I'm a bit of a history buff. I'm a
256
00:13:56.159 --> 00:14:00.440
bit of a history buff. So it's interesting because it
257
00:14:00.600 --> 00:14:04.159
was that period in time where RPC was effectively dying
258
00:14:04.840 --> 00:14:07.960
so our PC was really RPC. The term was coined
259
00:14:08.000 --> 00:14:11.960
in the eighties. It became really popular in the nineties
260
00:14:12.120 --> 00:14:17.720
with the native platforms for it like Corba or Dcom
261
00:14:18.080 --> 00:14:22.399
from Microsoft, and then the Web happened, which kind of
262
00:14:22.519 --> 00:14:27.039
killed it. Soap was an attempt to somehow continue to
263
00:14:27.120 --> 00:14:30.879
do RPC despite the Web, and we can talk about
264
00:14:30.919 --> 00:14:33.559
why the web killed RPC for a while at least,
265
00:14:34.279 --> 00:14:37.240
and now it's making a comeback in a much more
266
00:14:37.360 --> 00:14:40.600
natural way, which is in a lot of ways very
267
00:14:40.639 --> 00:14:45.159
reminiscent of how it was in the nineties, but compatible
268
00:14:45.279 --> 00:14:48.200
with the modern technologies that we use nowadays.
269
00:14:48.440 --> 00:14:51.600
Right, Yeah, yeah, I mean that sounds about right, Like
270
00:14:51.679 --> 00:14:55.039
no one was touching RPC after that early mid two
271
00:14:55.080 --> 00:14:58.840
thousands period until maybe like twenty twenty.
272
00:14:58.919 --> 00:15:03.720
Is they're like in the web technology, But.
273
00:15:03.960 --> 00:15:09.039
I mean yes, obviously, when we start designing these surver
274
00:15:09.080 --> 00:15:14.080
rendered meta frameworks where we actually have the server and
275
00:15:14.120 --> 00:15:18.240
the client being developed in the same place, you start
276
00:15:18.360 --> 00:15:21.080
going like, well, if I control both sides, why not
277
00:15:21.159 --> 00:15:22.600
like make that pipe easier.
278
00:15:23.039 --> 00:15:24.840
But I mean that was the motivation.
279
00:15:24.960 --> 00:15:28.080
The thing for me personally when I started looking at
280
00:15:28.080 --> 00:15:31.039
this stuff was I wasn't I was aware of this
281
00:15:31.159 --> 00:15:34.039
the soap stuff you know and that, But I was
282
00:15:34.080 --> 00:15:36.679
just trying to like I was looking at other meta frameworks,
283
00:15:36.840 --> 00:15:38.759
was this is the beginning of all start Like twenty
284
00:15:38.799 --> 00:15:41.159
twenty one is actually before I even really sold at
285
00:15:41.200 --> 00:15:42.799
one point zero, And I was like looking at other
286
00:15:42.840 --> 00:15:45.879
meta frameworks a bit, and I was looking like next
287
00:15:45.960 --> 00:15:50.879
JS and and mostly and like you know sapper from
288
00:15:51.200 --> 00:15:55.720
and like next and they all had these like API
289
00:15:55.919 --> 00:15:58.000
end points, like like where you'd like do this file
290
00:15:58.279 --> 00:16:03.639
based routing system with apien points. And the thing that
291
00:16:03.679 --> 00:16:04.919
was weird for me is I used to be a
292
00:16:05.000 --> 00:16:07.759
real guy for a bit, so like you would define
293
00:16:07.799 --> 00:16:11.360
like like in the file system, you'd define I guess
294
00:16:11.360 --> 00:16:13.120
not a file system was an auto madeive.
295
00:16:12.879 --> 00:16:13.639
Filesism, but whatever.
296
00:16:13.679 --> 00:16:17.519
You you skelton out these like models essentially and API
297
00:16:17.600 --> 00:16:20.279
n points and they would describe the whole collection of
298
00:16:20.320 --> 00:16:24.080
the whole model of things, and the filesystem approached a
299
00:16:24.080 --> 00:16:26.600
lot of these APIs had taken was kind of it
300
00:16:26.600 --> 00:16:30.120
felt weird to me because you'd have like a different
301
00:16:30.159 --> 00:16:35.120
file for like the general like groups versus like group
302
00:16:35.159 --> 00:16:37.279
I D like you didn't put all the crowd commands
303
00:16:37.320 --> 00:16:41.120
together like it would like separate based on the URL path,
304
00:16:41.200 --> 00:16:45.039
not based on the conceptual model, if that makes any sense,
305
00:16:45.039 --> 00:16:47.480
Like instead of being talking about groups as a single thing,
306
00:16:47.600 --> 00:16:50.559
you would have like groups and groups slash.
307
00:16:50.600 --> 00:16:52.639
I d like it's a funny thing.
308
00:16:53.000 --> 00:16:54.960
But I was looking at these API shapes and I
309
00:16:55.000 --> 00:16:56.799
was like, this is such a hassle to like every
310
00:16:56.840 --> 00:16:59.080
time I do this to build out these files.
311
00:17:01.600 --> 00:17:03.919
I saw Remix. I think this was for me.
312
00:17:04.680 --> 00:17:07.680
They did their big reveal in spring twenty twenty one,
313
00:17:07.720 --> 00:17:10.960
and I know this, and when I saw their loaders
314
00:17:11.039 --> 00:17:13.079
and actions and the way that they doubled it up
315
00:17:13.079 --> 00:17:15.200
on the API side, I'm like, this is kind of nice.
316
00:17:15.559 --> 00:17:19.599
It's like turned into a single approach, because what was
317
00:17:19.680 --> 00:17:22.039
kind of awkward was that people would build their app
318
00:17:22.039 --> 00:17:23.960
in one folder and then they'd build their API and
319
00:17:24.000 --> 00:17:26.200
another folder, and it was getting kind of clunky. You
320
00:17:26.359 --> 00:17:28.839
do everything twice, kind of connecting it up. And they
321
00:17:28.920 --> 00:17:30.480
were like, no, you can just kind of stick it
322
00:17:30.519 --> 00:17:32.799
all in the same place, follow the same kind of pattern.
323
00:17:33.440 --> 00:17:35.799
The challenge I had Remix is because I've been working
324
00:17:35.799 --> 00:17:39.880
on routing for a while and nested routing and with
325
00:17:40.000 --> 00:17:43.279
you know, parallel data fetching and all these things. Is
326
00:17:43.680 --> 00:17:47.519
the remix loader basically said that this part of the
327
00:17:47.599 --> 00:17:51.880
UL loads this data, and that wasn't granular enough for me.
328
00:17:51.960 --> 00:17:54.039
I was working a solid gazz which is based on singles.
329
00:17:54.039 --> 00:17:57.519
So as you can imagine, there's multiple different data sources.
330
00:17:57.519 --> 00:17:59.839
You want them to update independently, right, you want to
331
00:17:59.839 --> 00:18:03.039
be to refresh them independently. You only want to update
332
00:18:03.079 --> 00:18:05.279
certain parts of the page. Treating the whole page like
333
00:18:05.319 --> 00:18:09.680
it was like a single data flow was not particularly
334
00:18:10.279 --> 00:18:12.920
nice for me. So I was like, okay, can I
335
00:18:12.960 --> 00:18:16.759
take my kind of like route loaders, which are they're
336
00:18:16.799 --> 00:18:19.319
not really loaders, they're isomorphic. They run on both sides,
337
00:18:19.680 --> 00:18:23.440
these kind of nested rout kind of areas where you
338
00:18:23.440 --> 00:18:26.359
can fetch data and instead of you know, hitting API
339
00:18:26.440 --> 00:18:28.759
calls like we used to, instead of using one single loader,
340
00:18:28.960 --> 00:18:32.480
can we make it more ergonomic to define individual pieces
341
00:18:32.480 --> 00:18:35.759
of data you can fetch. And I was looking when
342
00:18:35.759 --> 00:18:37.200
I was doing the client side, and I'm like, I
343
00:18:37.240 --> 00:18:39.920
love this. You know I can put you know, you know,
344
00:18:40.119 --> 00:18:42.079
solid query. This is like a ten I rack in
345
00:18:42.119 --> 00:18:44.079
the conversation for a second, but like I can put
346
00:18:44.279 --> 00:18:47.519
like my different data fetching things inside this loading and
347
00:18:47.559 --> 00:18:49.799
I can manage them separately. If I'm on this page,
348
00:18:49.880 --> 00:18:53.000
can I can grab users and their posts and have
349
00:18:53.079 --> 00:18:57.519
multiple things and call them and invalidate them separately. And
350
00:18:57.559 --> 00:19:00.160
I'm like, this is a great pattern. It works on
351
00:19:00.160 --> 00:19:03.200
the server, works on the client. The only problem is
352
00:19:03.400 --> 00:19:06.240
you have to call these extra API in points. So
353
00:19:07.079 --> 00:19:10.319
I started working on a solution, which was, what if
354
00:19:10.359 --> 00:19:13.079
I could use the file system in a nicer way,
355
00:19:13.200 --> 00:19:15.599
like better than the API in points, where instead of
356
00:19:15.799 --> 00:19:18.400
being quite as bulky and like having these URLs, I
357
00:19:18.400 --> 00:19:21.240
could use like a proxy or something like where you
358
00:19:21.279 --> 00:19:24.359
could maybe make some types for an object, and based
359
00:19:24.400 --> 00:19:26.519
on what path you go through the object, it would
360
00:19:26.559 --> 00:19:28.960
construct the URL on the client and then know what
361
00:19:29.079 --> 00:19:32.039
endpoint to hit on the server. And I kind of
362
00:19:32.079 --> 00:19:35.200
put this together and I call them actions after remixes actions.
363
00:19:35.240 --> 00:19:39.079
And the difference is they weren't really exactly actions, or
364
00:19:39.119 --> 00:19:41.000
they were both actions and loaders. You could basically hit
365
00:19:41.000 --> 00:19:43.640
these URLs both on data fetching and on mutation, and
366
00:19:43.680 --> 00:19:47.559
you could call them They're just like autogeneratid APIs. And
367
00:19:48.119 --> 00:19:50.799
I remember I put that out around April. I made
368
00:19:50.839 --> 00:19:53.759
some demos around April twenty twenty one, but then Solid
369
00:19:53.799 --> 00:19:55.279
one point zero needed to get released, and I put
370
00:19:55.279 --> 00:19:59.559
it aside, and I basically was like showing people and
371
00:19:59.799 --> 00:20:01.920
talk like how cool this was going to be, but
372
00:20:02.319 --> 00:20:04.240
you know, people just like, oh, yeah, yeah, whatever, Ryan,
373
00:20:04.440 --> 00:20:07.720
and and then and then it was almost a year later.
374
00:20:08.200 --> 00:20:10.759
It could be fair half of us don't know, don't
375
00:20:11.400 --> 00:20:13.680
often don't understand what you're talking about, so.
376
00:20:13.640 --> 00:20:17.079
That that's that's perfectly fair. But some people did.
377
00:20:17.119 --> 00:20:20.480
And I was talking to someone in December or like
378
00:20:20.480 --> 00:20:22.680
around Christmas time, and they're like, oh, isn't that what
379
00:20:22.720 --> 00:20:26.920
blitz JS is. I'm like, Blitz, isn't that next JSS thing?
380
00:20:27.400 --> 00:20:29.440
And I look at it, and sure enough, that is
381
00:20:29.559 --> 00:20:33.400
actually what blitz was. I basically independently also came up
382
00:20:33.440 --> 00:20:34.960
something similar to what Blitz was.
383
00:20:34.920 --> 00:20:37.440
Which is blitz what is it?
384
00:20:37.440 --> 00:20:37.720
It was?
385
00:20:37.799 --> 00:20:40.799
It was it was kind of like a meta framework
386
00:20:40.839 --> 00:20:43.960
on top of Next. I thought it was like Redwood,
387
00:20:44.039 --> 00:20:46.119
like it was one of those more opinionated meta frameworks
388
00:20:46.160 --> 00:20:49.200
on top of Next. But eventually they just became like
389
00:20:49.240 --> 00:20:53.079
a Next plug in and kind of downscaled it because
390
00:20:53.119 --> 00:20:54.799
but originally it was like a separate product, like you
391
00:20:54.880 --> 00:20:58.839
when installed Next, you install Blitz, and it was it
392
00:20:58.880 --> 00:21:02.200
was a React meta frame essentially. But it's cool feature
393
00:21:02.319 --> 00:21:06.759
was that it had these basically kind of generated API
394
00:21:07.039 --> 00:21:09.839
functions in the same kind of way that I was describing,
395
00:21:10.799 --> 00:21:16.279
where you could just kind of put these basically API
396
00:21:16.359 --> 00:21:18.720
call things in a file folder structure and then call
397
00:21:18.759 --> 00:21:21.519
them directly without like the fetch and the ceremony around
398
00:21:21.559 --> 00:21:23.720
like that. You could just call them basically it's functions
399
00:21:23.839 --> 00:21:26.880
via like a proxy like I was talking about, because
400
00:21:27.359 --> 00:21:30.279
the cool thing that the proxy approaches you can have
401
00:21:30.279 --> 00:21:32.519
the proxy return whatever you want, so it just wraps
402
00:21:32.559 --> 00:21:35.720
the details of the fetch away from you. So it
403
00:21:35.799 --> 00:21:37.799
is kind of the beginning of this RPC thing because
404
00:21:37.799 --> 00:21:40.160
you still have the API point where you have a
405
00:21:40.160 --> 00:21:43.559
file system running telling you like basically where these functions are.
406
00:21:43.640 --> 00:21:45.559
But then you could use the path on the proxy
407
00:21:45.680 --> 00:21:49.559
like get users dot get or like whatever to actually
408
00:21:49.559 --> 00:21:53.359
construct the URL and obscure the fetching. And I know
409
00:21:53.400 --> 00:21:55.680
this is kind of crazy history, but you know, like
410
00:21:56.000 --> 00:21:57.799
beyond where we ended up, but it was important for
411
00:21:57.839 --> 00:21:59.039
me to get there because when I went back to
412
00:21:59.039 --> 00:22:01.480
solid Start and after playing with this again, by this
413
00:22:01.559 --> 00:22:04.559
time I had met Nikhil Sarah, who was kind of
414
00:22:04.799 --> 00:22:08.880
responsible for a lot of stuff in solid ecosystem. He
415
00:22:09.119 --> 00:22:11.240
did a lot of the heavy lifting on the original
416
00:22:11.240 --> 00:22:15.519
salt Start release, and he also created Vinci, which we
417
00:22:15.680 --> 00:22:18.160
used to actually base salts Start and tasks Start initially.
418
00:22:18.519 --> 00:22:21.599
And he was like, man, veat is amazing. We don't
419
00:22:21.599 --> 00:22:23.640
need to use all this proxy stuff. We can just
420
00:22:23.839 --> 00:22:27.480
use a compiler and split these things out, like even
421
00:22:27.519 --> 00:22:29.559
in the middle of the files, like it doesn't matter.
422
00:22:29.559 --> 00:22:32.440
He started doing crazy stuff where he was analyzing like
423
00:22:33.400 --> 00:22:36.279
things further down the tree and hoisting them automatically and
424
00:22:36.279 --> 00:22:38.799
doing like all this stuff. And I'm like, this is crazy.
425
00:22:38.880 --> 00:22:43.240
I can't even wrap my head around what's happening. But
426
00:22:43.519 --> 00:22:45.240
he's like, look, as long as we have a symbol,
427
00:22:45.400 --> 00:22:47.079
like some way of it's saying like this is a
428
00:22:47.839 --> 00:22:50.240
is a function call, we don't need to use the
429
00:22:50.240 --> 00:22:52.279
file system. We can just go like this is a
430
00:22:52.359 --> 00:22:55.799
server function or whatever, and we passed the function to it,
431
00:22:56.119 --> 00:22:59.920
and now that function will always be called on the server.
432
00:23:00.759 --> 00:23:03.240
This is where you guys invented bling. I think you
433
00:23:03.359 --> 00:23:04.720
called it back then, right.
434
00:23:04.680 --> 00:23:06.680
Yes, almost.
435
00:23:06.799 --> 00:23:10.079
Bling would come very soon soon when we brought Tanner in.
436
00:23:10.119 --> 00:23:15.240
On Tanner, what this I actually presented our original version
437
00:23:15.519 --> 00:23:18.640
like this at vcomp the first b COMP back in
438
00:23:19.000 --> 00:23:22.279
September twenty twenty two, and that's when people were like, oh,
439
00:23:22.480 --> 00:23:24.119
this is actually kind of cool, you know, because it
440
00:23:24.200 --> 00:23:26.920
had types like when you start having functions and you
441
00:23:26.920 --> 00:23:28.839
can write them like functions where you can just import
442
00:23:28.880 --> 00:23:31.240
them the types match up.
443
00:23:32.000 --> 00:23:35.559
Yeah, And I'll get to that because it brings an
444
00:23:35.599 --> 00:23:40.440
interesting point from my perspective about why RPC is so
445
00:23:40.519 --> 00:23:44.880
attractive and what changed, because we talked about how the
446
00:23:44.920 --> 00:23:47.839
web kind of killed RPC, so it's interesting to talk
447
00:23:47.880 --> 00:23:51.039
about how RPC was able to make this kind of comeback.
448
00:23:51.319 --> 00:23:53.640
But before we go there, Tanner, I really want to
449
00:23:53.640 --> 00:23:55.519
bring you into the conversation finally.
450
00:23:56.079 --> 00:23:59.400
So I mean, it is basically almost at that point
451
00:23:59.440 --> 00:24:04.079
because Tanner is really into types. So after I demoed
452
00:24:04.119 --> 00:24:06.559
this stuff and the type stuff, what came out in
453
00:24:07.519 --> 00:24:09.279
the world that we realized that, like, what's cool, You
454
00:24:09.319 --> 00:24:11.400
can literally write the function as is. You don't you
455
00:24:11.440 --> 00:24:13.200
know a lot of type things that graft you or whatever.
456
00:24:13.200 --> 00:24:15.640
You'd have to write these schemas were this the types
457
00:24:15.880 --> 00:24:19.839
inherent off the functions simply from importing them automatical transferred.
458
00:24:19.880 --> 00:24:21.240
You didn't have to do anything you wouldn't be doing
459
00:24:21.319 --> 00:24:25.680
usually for typing. So once once we uh basically realized that,
460
00:24:27.000 --> 00:24:31.240
uh you know, uh, I started kind of publishing it
461
00:24:31.279 --> 00:24:34.720
out there and talking to other people. I was like, man,
462
00:24:35.279 --> 00:24:37.599
I still couldn't get over how magical it felt. And
463
00:24:37.640 --> 00:24:39.599
then I looked over it Quick and I was like,
464
00:24:40.000 --> 00:24:42.039
maybe we just need a better symbol. So I was like,
465
00:24:42.160 --> 00:24:44.720
let's add a dollar sign on it. And I actually
466
00:24:44.759 --> 00:24:46.720
told the Quick guys like they didn't know I did this,
467
00:24:46.759 --> 00:24:50.039
and I was like, I was tarting to manual In
468
00:24:50.519 --> 00:24:52.599
at a conference in that fall, and I was like, man,
469
00:24:53.119 --> 00:24:55.400
I think Quick could add this. I honestly stole your
470
00:24:55.400 --> 00:24:58.240
guys's dollar sign just because it's like a good indicator.
471
00:24:58.279 --> 00:25:00.279
And I'm like, we can just like you. It's just
472
00:25:00.319 --> 00:25:01.480
the reverse of what Quick does.
473
00:25:01.559 --> 00:25:03.559
Quick it was really good at pulling out these little
474
00:25:03.559 --> 00:25:06.279
pieces on the client. This is like pulling out these
475
00:25:06.279 --> 00:25:08.720
little pieces for the server. It's just like inverse Quick
476
00:25:08.759 --> 00:25:12.200
and they added it to their meta framework within a
477
00:25:12.200 --> 00:25:14.640
month after that conversation, like they were just like, yeah,
478
00:25:14.640 --> 00:25:17.279
we already have everything here, and they did it almost immediately.
479
00:25:17.519 --> 00:25:21.359
And as said, that's when tanner Gun involved around that point. Oh,
480
00:25:21.400 --> 00:25:23.440
actually it might have been even a little bit later,
481
00:25:23.640 --> 00:25:27.240
is around when next Uh and React they were like
482
00:25:27.640 --> 00:25:30.160
saw this stuff too, and they're like, oh, and they
483
00:25:30.200 --> 00:25:33.279
came up with like use server, but it was specific
484
00:25:33.279 --> 00:25:38.440
for their for their rpcs, for their server function communication.
485
00:25:38.039 --> 00:25:41.039
Their Initially they actually had it in the fine names
486
00:25:41.039 --> 00:25:44.880
if you recall the dot server dot ts and dot
487
00:25:44.920 --> 00:25:45.839
client dot t s.
488
00:25:46.319 --> 00:25:48.480
That was that was the catalyst for me right there.
489
00:25:48.640 --> 00:25:50.359
Yeah, I mean there there was there was like a
490
00:25:50.400 --> 00:25:56.920
subtle different like put it because technically server functions start
491
00:25:56.960 --> 00:26:00.240
on the server and there's like a naming convention where
492
00:26:00.240 --> 00:26:02.079
they're like, okay, these are server, these are client, and
493
00:26:02.119 --> 00:26:06.279
these are shared. But then like it's a different scenario
494
00:26:06.359 --> 00:26:08.599
because the server stuff can be done all in a
495
00:26:08.640 --> 00:26:11.759
single pass, like in a single go. They when they
496
00:26:11.799 --> 00:26:14.680
originally came up with that, that was to denote server functions,
497
00:26:14.720 --> 00:26:19.599
but not sorry, server components, not necessarily server functions, right or.
498
00:26:19.480 --> 00:26:24.440
Like they didn't have an aultation. Use client came as
499
00:26:24.480 --> 00:26:28.519
an alternative to dot server and dot client my fine names.
500
00:26:28.799 --> 00:26:33.519
They didn't have anything for you server, which came around.
501
00:26:33.240 --> 00:26:36.680
Later, right exactly, So they started proposing this stuff and
502
00:26:37.000 --> 00:26:38.839
I mean, yeah, Tenner can jump in at this point,
503
00:26:38.880 --> 00:26:40.839
but I think he saw what they were doing and
504
00:26:40.839 --> 00:26:42.119
it was just like, what the hell is this?
505
00:26:43.799 --> 00:26:46.200
I didn't I mean, I thought it was neat. I
506
00:26:46.240 --> 00:26:49.240
was more interested in, like what they were doing under
507
00:26:49.240 --> 00:26:52.359
the hood with like the compilation, what was actually happening
508
00:26:52.440 --> 00:26:57.039
to the build and transforming that the AST and whatnot.
509
00:26:57.160 --> 00:27:03.720
But I did not really like the approach to like
510
00:27:04.599 --> 00:27:08.880
use client use server at least for like RPC. I
511
00:27:08.920 --> 00:27:13.240
looked at it and I was excited about like, oh,
512
00:27:13.359 --> 00:27:16.720
I can just throw this token in there and all
513
00:27:16.720 --> 00:27:19.599
of a sudden creat an RPC, and like that part's cool.
514
00:27:20.400 --> 00:27:23.839
But then all these questions started bubbling up about like, Okay,
515
00:27:24.640 --> 00:27:30.000
clearly they don't believe that like configuring and RPC is
516
00:27:30.039 --> 00:27:33.839
as simple as a one string Like that's ridiculous.
517
00:27:33.960 --> 00:27:36.720
So I want to touch that briefly again to give
518
00:27:37.240 --> 00:27:40.640
a little bit of context to our listeners. So we
519
00:27:40.720 --> 00:27:45.119
talked about the fact that RPC is about invoking a
520
00:27:45.240 --> 00:27:49.039
function somewhere else as if it's a local fun a
521
00:27:49.079 --> 00:27:54.359
local function, and specifically in the context of full stack frameworks,
522
00:27:54.720 --> 00:27:59.759
it's basically invoking a server side function from client side
523
00:27:59.759 --> 00:28:03.160
code using the function called paradigm. So it looks and
524
00:28:03.200 --> 00:28:05.640
feels like a function. Now, in order to be able
525
00:28:05.720 --> 00:28:08.720
to do that, you kind of need to have, from
526
00:28:08.759 --> 00:28:12.960
my perspective, three things. First of all, you need to
527
00:28:13.000 --> 00:28:17.359
have type safety. Otherwise what's the point and going back
528
00:28:17.400 --> 00:28:21.039
to your or to your point, Ryan ab when disappeared,
529
00:28:21.079 --> 00:28:25.279
Obviously it only came into being after Typescript really went mainstream,
530
00:28:25.400 --> 00:28:32.799
because before Typescript, the whole typing thing was irrelevant. And
531
00:28:33.240 --> 00:28:37.279
the other thing that you need is to be able
532
00:28:37.319 --> 00:28:41.400
to simulate blocking you call to the remote function. You
533
00:28:41.440 --> 00:28:45.240
want to have it to feel like a local function,
534
00:28:45.319 --> 00:28:49.720
which means you don't get the execution back until that
535
00:28:49.759 --> 00:28:53.640
remote function finishes and provides a value. And we only
536
00:28:53.680 --> 00:28:55.640
got that after we got a sinkle weight.
537
00:28:56.240 --> 00:28:59.880
Basically, yeah, yeah, I mean, I'm native support of promise is,
538
00:29:00.039 --> 00:29:03.359
but more specific to this conversation, when framework started having
539
00:29:04.079 --> 00:29:05.839
tools to do what they think, which secularly you know.
540
00:29:06.160 --> 00:29:10.119
And which brings me back to the final point is ideally,
541
00:29:10.480 --> 00:29:14.599
not necessarily, but ideally you also want what you mentioned
542
00:29:14.640 --> 00:29:20.079
about vat, the ability to effectively instrument the code basically
543
00:29:20.279 --> 00:29:24.000
write something that looks like a function call, identify that
544
00:29:24.079 --> 00:29:25.920
this code is going to be running on the client,
545
00:29:26.240 --> 00:29:28.480
this code is going to be running on the server
546
00:29:28.880 --> 00:29:32.799
and generate all the magic code that makes this thing work. Basically,
547
00:29:32.839 --> 00:29:37.119
it's it's a stub and on the client and on
548
00:29:37.160 --> 00:29:41.920
the server that handles the whole networking layer underneath that
549
00:29:42.200 --> 00:29:42.960
function call.
550
00:29:43.559 --> 00:29:45.440
Now I'm mentioning that you don't.
551
00:29:45.359 --> 00:29:51.839
Necessarily have to have it because types trpc does without it,
552
00:29:52.559 --> 00:29:58.799
which makes it less magical and and also less fun. Potentially,
553
00:30:00.160 --> 00:30:03.599
going back to I want to give Tanner, I basically
554
00:30:03.640 --> 00:30:08.039
stole the mic from Tanner. So Tanner, you said that
555
00:30:08.319 --> 00:30:12.359
you looked at that the fact that they introduced this
556
00:30:12.480 --> 00:30:15.119
kind of magic string and all of a sudden it
557
00:30:15.319 --> 00:30:18.599
kind of worked, and you had thoughts about.
558
00:30:18.359 --> 00:30:27.160
That, Yeah, because like details matter eventually, details matter a lot.
559
00:30:27.480 --> 00:30:31.960
Like I think what you see is like you you
560
00:30:32.119 --> 00:30:37.079
write use server and a function, and that's that's really magical,
561
00:30:37.599 --> 00:30:40.400
and it's it's magical both in a sense of like
562
00:30:40.880 --> 00:30:44.039
it's doing a lot under the hood for you, but
563
00:30:44.119 --> 00:30:50.720
it's also a magical experience for most like basic operations
564
00:30:50.799 --> 00:30:55.400
or basic use cases. It's so simple, it's deceptively simple
565
00:30:55.519 --> 00:30:57.480
that it's like, oh, that's all it takes, right, and
566
00:30:57.519 --> 00:31:00.720
you just you put U server in there, But there's
567
00:31:00.799 --> 00:31:05.799
so many details that bubble up that you cannot get
568
00:31:05.799 --> 00:31:10.319
away from the fact that this is happening over the network.
569
00:31:10.759 --> 00:31:17.400
There are implementation details there that matter sometimes and there
570
00:31:17.559 --> 00:31:27.039
for example, yeah, caching protocol methods, header's authentication. There's there's
571
00:31:27.119 --> 00:31:31.839
like edge case flexibility that needs to be inherently in
572
00:31:31.880 --> 00:31:34.599
the system to allow you to do things that you
573
00:31:34.839 --> 00:31:38.079
maybe don't do ninety percent of the time, but you
574
00:31:38.119 --> 00:31:42.079
will need to do. One of the basic ones was
575
00:31:44.000 --> 00:31:48.640
you server defaults to a post sorry not be defaults.
576
00:31:48.680 --> 00:31:53.400
It is a post request in like next jays and
577
00:31:53.480 --> 00:31:56.359
React reacts to kind of spec right.
578
00:31:56.519 --> 00:31:59.279
You also don't have any control, like you said, either
579
00:31:59.359 --> 00:32:01.559
over the end point all the protocol.
580
00:32:01.440 --> 00:32:05.240
No or headers or anything like that. You're you can
581
00:32:05.839 --> 00:32:08.119
kind of get it some of the implementation, but only
582
00:32:08.200 --> 00:32:11.480
at like a global place. But if you wanted to
583
00:32:11.519 --> 00:32:14.559
customize any of that other stuff, you can't really do that,
584
00:32:14.759 --> 00:32:16.759
and you have to break out of the system entirely.
585
00:32:17.440 --> 00:32:21.119
And I didn't like that because immediately I was like, well,
586
00:32:21.160 --> 00:32:24.640
I want to use this with reac query, and that's
587
00:32:24.640 --> 00:32:27.720
great for cashing, But wouldn't it be great if if
588
00:32:27.759 --> 00:32:31.319
the browser could actually just cash this get request that
589
00:32:31.359 --> 00:32:35.119
I'm making, it's totally capable of doing that. And then
590
00:32:35.119 --> 00:32:39.160
there's questions of well, how is that URL formulated in
591
00:32:39.200 --> 00:32:42.039
a way that's going to be stable for the browser
592
00:32:42.039 --> 00:32:44.720
to cash, And there's lots of questions that came up
593
00:32:44.720 --> 00:32:47.640
for me around that, and I just knew at one
594
00:32:47.720 --> 00:32:51.480
point we're going to need to like ninety percent of
595
00:32:51.519 --> 00:32:54.920
the time same experience as just use server. Just create
596
00:32:54.960 --> 00:32:57.039
a function, give it some kind of a symbol, a
597
00:32:57.119 --> 00:33:00.759
dollar sign or something that would make it easy for
598
00:33:01.039 --> 00:33:04.200
a bulk of the use cases, and then have at
599
00:33:04.319 --> 00:33:08.880
least the ability or the option to expand and and
600
00:33:09.119 --> 00:33:13.599
make that configuration advanced. I just don't understand when people
601
00:33:13.680 --> 00:33:18.480
create APIs that cannot be ripped away easily or like
602
00:33:18.559 --> 00:33:22.119
dug into easily. I don't understand it. And these directives
603
00:33:22.160 --> 00:33:25.839
of use server or use cash or whatever are like
604
00:33:25.960 --> 00:33:28.160
the biggest offenders of that principle for me.
605
00:33:28.839 --> 00:33:34.000
So it's it's funny because as you get guys may
606
00:33:34.039 --> 00:33:36.680
not know actually I started with server functions, solid uses
607
00:33:36.759 --> 00:33:42.200
use server today because compatibility with react or like conceptually
608
00:33:42.480 --> 00:33:44.759
there yes, wrapper functions are.
609
00:33:45.559 --> 00:33:49.039
By the way, like intense sex start you can write
610
00:33:49.160 --> 00:33:52.200
use server ye and you'll get the same experience.
611
00:33:52.279 --> 00:33:56.519
But it's yeah, like rapper functions are as tenders that
612
00:33:56.559 --> 00:34:01.480
are almost necessary for configuration. And that's like positively at
613
00:34:01.519 --> 00:34:07.039
least is that because this configuration comes from the client,
614
00:34:07.359 --> 00:34:09.840
wrapping is definitely something you can do, Like you can
615
00:34:10.239 --> 00:34:13.280
compose these kind of pieces on top of server functions
616
00:34:13.320 --> 00:34:17.679
because the server parts on the server, the use server,
617
00:34:17.840 --> 00:34:21.800
the server offs and represents the split between the like
618
00:34:21.880 --> 00:34:23.440
this goes on server, this goes in the client.
619
00:34:23.559 --> 00:34:25.000
So it's basically.
620
00:34:26.880 --> 00:34:29.239
One of the things that kind of enabled I'll give
621
00:34:29.239 --> 00:34:31.840
you in a second just mentioning that one of the
622
00:34:31.880 --> 00:34:34.960
things that enabled this whole thing is like you mentioned
623
00:34:34.960 --> 00:34:38.760
when we talked about VAT, is that smart bundler that's
624
00:34:39.079 --> 00:34:42.519
that's analyzing the code in any event, sees it and
625
00:34:42.559 --> 00:34:45.519
then knows to generate different code for the server and
626
00:34:45.639 --> 00:34:48.440
different code for the client from the same source code. Right,
627
00:34:49.039 --> 00:34:50.360
That's the sweet magic.
628
00:34:50.800 --> 00:34:53.119
We should talk about beat here for a little bit more,
629
00:34:53.239 --> 00:34:57.519
because the thing is at this point Tenner and I
630
00:34:57.599 --> 00:35:00.679
are talking the keel and we're like every framework could
631
00:35:00.760 --> 00:35:00.920
use this.
632
00:35:00.960 --> 00:35:01.840
Why just use this.
633
00:35:01.800 --> 00:35:05.239
Only in solid Why have you know, you know, quick
634
00:35:05.320 --> 00:35:08.760
make their own version. Why have next make their own version?
635
00:35:10.000 --> 00:35:14.360
And Antenner was like, okay, let's let's like just make
636
00:35:14.400 --> 00:35:16.679
a generic plugin for this, right, So that's where Blain
637
00:35:16.800 --> 00:35:19.760
came about. When it was like Kennedy, he picked it
638
00:35:19.800 --> 00:35:22.440
up and he was like, let's let's make this generic.
639
00:35:22.480 --> 00:35:23.880
The thing that is.
640
00:35:23.840 --> 00:35:28.239
Bling didn't quite survive in the same form because what
641
00:35:28.280 --> 00:35:32.039
we realized was Blain was basically like a was it
642
00:35:32.079 --> 00:35:34.440
a Babel plug in. It was basically a transform. It
643
00:35:34.519 --> 00:35:41.559
basically transformed a code without bundler awareness, which does work
644
00:35:42.559 --> 00:35:45.159
a lot in this in the simple cases, but it
645
00:35:45.199 --> 00:35:49.159
doesn't work in the more complicate cases, mainly that if
646
00:35:50.159 --> 00:35:52.320
how do you register these endpoints?
647
00:35:53.039 --> 00:35:53.239
Right?
648
00:35:53.480 --> 00:35:56.880
Real apps have code splitting, so you might not load
649
00:35:56.920 --> 00:35:58.960
all the code in the client, or you might not
650
00:35:59.000 --> 00:36:02.000
load all the code on the server. And what ended
651
00:36:02.079 --> 00:36:05.840
up happening with the just doing a compiler approach was
652
00:36:06.000 --> 00:36:09.159
that we would sometimes navigate to a page on the
653
00:36:09.159 --> 00:36:13.119
client that hadn't been navigated to on the server, which
654
00:36:13.199 --> 00:36:15.800
means the endpoint wouldn't be registered yet.
655
00:36:15.639 --> 00:36:18.199
It didn't exist yet, so it didn't even occur to me.
656
00:36:18.920 --> 00:36:22.800
So like basically, this generic approach, it wasn't enough just
657
00:36:22.800 --> 00:36:25.079
to stop a babble and a compiler. We needed something
658
00:36:25.119 --> 00:36:28.239
that would actually go through the whole module graph and
659
00:36:28.960 --> 00:36:33.199
oist out these things, and it had to be bundler level.
660
00:36:33.320 --> 00:36:36.760
So this is that's that's actually why Blaine died. In
661
00:36:36.760 --> 00:36:38.480
a sense, Tannor has remade.
662
00:36:38.880 --> 00:36:42.880
It was repurposed, right. Actually, what's funny is like a
663
00:36:42.880 --> 00:36:46.519
lot of the code from Bling made it into VINI.
664
00:36:47.239 --> 00:36:50.159
Yes, yeah, yeah, I mean at the VAT.
665
00:36:50.039 --> 00:36:52.920
Level, right, And then what's funny is then eventually we
666
00:36:53.039 --> 00:36:54.400
ripped it back out.
667
00:36:54.719 --> 00:36:56.679
Right, and the other part of Vinci ended up going
668
00:36:56.679 --> 00:37:00.559
directly to VAT when VEAT adopted the environment's API, because
669
00:37:00.599 --> 00:37:04.920
we're building these things and the VAT team had, I
670
00:37:04.920 --> 00:37:07.239
guess their own problem with deployment, like the solved with
671
00:37:07.239 --> 00:37:09.440
the deployment environments, like you have cloud Flare, which is
672
00:37:09.440 --> 00:37:12.079
different than Netlify and Bursell, and you could build for
673
00:37:12.199 --> 00:37:15.800
like different outputs like workers versus pages and all these
674
00:37:15.840 --> 00:37:19.239
things people wanted to have, like you know and client preserved.
675
00:37:19.400 --> 00:37:23.599
They want to have these different environments. Vinci actually did
676
00:37:23.639 --> 00:37:26.440
that because VAT didn't. It was hard to manage these
677
00:37:26.519 --> 00:37:30.920
kind of things, and.
678
00:37:29.199 --> 00:37:31.000
That's why we created it. And in the end.
679
00:37:31.400 --> 00:37:33.960
As I said, VINCI now has kind of been dismantled,
680
00:37:34.320 --> 00:37:37.960
but the environment API now exists in Beat very similar
681
00:37:38.199 --> 00:37:40.199
seeing usage to how we used to do it in VINCI,
682
00:37:40.639 --> 00:37:45.559
and we still have the server functions plug in in
683
00:37:45.599 --> 00:37:48.400
the form of what what's under Tanstak that's now used
684
00:37:48.440 --> 00:37:51.039
both by Soul, certain tank Tack start Tanner.
685
00:37:51.320 --> 00:37:55.280
You're very polite. You raise your hand.
686
00:37:56.079 --> 00:37:59.760
Oh, I was. I was gonna say. One of your
687
00:38:00.039 --> 00:38:02.559
questions went unanswered, and I wanted to answer it before
688
00:38:02.599 --> 00:38:05.519
we went too deep into compiler land. And it was
689
00:38:05.559 --> 00:38:10.360
about type safety, and that is a massive part of
690
00:38:11.519 --> 00:38:16.159
another massive reason of why it all went this direction
691
00:38:16.239 --> 00:38:21.880
for me, and it's it's also because type safety. A
692
00:38:21.920 --> 00:38:24.599
lot of people think, well, it's just defining, you know,
693
00:38:24.880 --> 00:38:29.920
the types that this function can take on. But in
694
00:38:29.960 --> 00:38:34.360
reality you're not just writing typescript types and expecting those
695
00:38:34.400 --> 00:38:39.760
to get extracted away into validation. Because that's another that's
696
00:38:39.800 --> 00:38:42.960
another part where like just sending, just treating it like
697
00:38:43.000 --> 00:38:47.920
a function still is not totally safe. I mean, I
698
00:38:48.039 --> 00:38:49.840
like it that we that we want to get to
699
00:38:49.880 --> 00:38:52.960
this functional zintax of just calling the function and having
700
00:38:53.039 --> 00:38:57.000
it be awaited, and it's it's really nice, but under
701
00:38:57.000 --> 00:38:59.480
the hood, it's these details you need to be aware
702
00:38:59.519 --> 00:39:01.840
of them, and one of them is that you're going
703
00:39:01.840 --> 00:39:06.320
across the network. So type safety without validation is a
704
00:39:06.360 --> 00:39:11.320
complete lie. You can validate anytime you go across a
705
00:39:11.440 --> 00:39:15.960
serialization boundary, even into the URL or local storage, anywhere
706
00:39:16.400 --> 00:39:18.960
you have to validate or it's just a lie.
707
00:39:19.440 --> 00:39:22.719
So yeah, it's really I'll let you continue in a second.
708
00:39:22.719 --> 00:39:26.639
I'm just clarifying again the terminology. It's that distinction between
709
00:39:27.119 --> 00:39:31.000
dev time type safety, maybe even build time type safety
710
00:39:31.400 --> 00:39:33.800
and run time type safety.
711
00:39:33.480 --> 00:39:39.000
Static type checking versus actually run time validation.
712
00:39:38.960 --> 00:39:43.679
And exactly in Typescript very intentionally does not do any
713
00:39:44.239 --> 00:39:47.199
run type type checking. So the fact that you're building
714
00:39:47.400 --> 00:39:51.079
on that you're leveraging Typescript types is really cool. You
715
00:39:51.119 --> 00:39:55.320
get completion, you get squiggly lines during development, but at
716
00:39:55.400 --> 00:39:59.119
runtime over the network, anything might be sent, especially if
717
00:39:59.159 --> 00:40:01.159
it's like a public point.
718
00:40:00.880 --> 00:40:03.280
Right and you know, you might feel like you're just
719
00:40:03.360 --> 00:40:07.239
writing a function and it might feel secure, But no
720
00:40:07.280 --> 00:40:09.800
one in their right mind would create a rest endpoint
721
00:40:10.280 --> 00:40:14.159
straight into their back end and not validate the inputs
722
00:40:14.199 --> 00:40:18.719
that they're getting from people. And so the same way here,
723
00:40:18.760 --> 00:40:21.840
like you you want to be validating the inputs going
724
00:40:21.840 --> 00:40:26.960
across these functions in a special way that isn't just oh,
725
00:40:27.039 --> 00:40:29.320
it's a typescript type. So I'm just going to trust
726
00:40:29.360 --> 00:40:32.360
that I'm the only one calling it and that my
727
00:40:32.480 --> 00:40:34.599
system is the only one that has access to this
728
00:40:35.039 --> 00:40:39.239
public RPC endpoint. Like all this stuff is easily reverse
729
00:40:39.320 --> 00:40:41.800
engineered and abused.
730
00:40:42.119 --> 00:40:46.480
It's even worse because when you're doing posts like straight
731
00:40:46.559 --> 00:40:51.360
on RESTful APIs, you know that you know that you're
732
00:40:51.400 --> 00:40:53.400
going to have to check the types. You're going to
733
00:40:53.480 --> 00:40:55.119
have to effectively cast the types.
734
00:40:55.440 --> 00:40:59.519
Yeah, because when you're losing the types perfectly going into
735
00:40:59.559 --> 00:41:03.199
this exactly on transform mechanism and pulling them back out
736
00:41:03.280 --> 00:41:06.960
on the server side, you know you you have to
737
00:41:06.960 --> 00:41:09.519
do the same thing coming back out. Otherwise it's like, well,
738
00:41:09.519 --> 00:41:11.800
this is just a blob of whatever, you know.
739
00:41:13.679 --> 00:41:17.039
I think, yeah, and with and and I forget if
740
00:41:17.039 --> 00:41:20.519
it was Rich Harris or Lirental who literally showed me
741
00:41:20.599 --> 00:41:25.079
an example I think where they used typescript and instead
742
00:41:25.159 --> 00:41:29.360
of a certain value pass vr PC being like saying
743
00:41:29.440 --> 00:41:32.360
just a string, they said it needs to be like
744
00:41:33.679 --> 00:41:40.880
the quote unquote quote child or quote teacher and nothing
745
00:41:40.920 --> 00:41:43.639
at run time validates that some other string is not
746
00:41:43.760 --> 00:41:48.440
passed in so you so typescript literally lies to you
747
00:41:48.519 --> 00:41:51.159
in this case if you're not careful.
748
00:41:51.079 --> 00:41:54.159
Which typescript needs to come after that, which is it
749
00:41:54.199 --> 00:41:58.920
needs to be a byproduct. And that's exactly why we
750
00:41:58.920 --> 00:42:02.400
we did two things. One we adopted Standard Schema. I mean,
751
00:42:02.440 --> 00:42:06.760
we helped kind of push standard Schema into reality. It
752
00:42:06.800 --> 00:42:09.840
was created by all the brilliant people that build these
753
00:42:09.920 --> 00:42:16.679
validation libraries like yeah, like like ZOD and type, archetype
754
00:42:16.719 --> 00:42:19.840
and stuff like that. But but we needed validation, so
755
00:42:19.880 --> 00:42:22.639
we did validation first. And what's interesting is with with
756
00:42:22.719 --> 00:42:28.320
our APIs to create our PCs, we do not allow you.
757
00:42:29.440 --> 00:42:31.119
I mean, you can do anything you want, but I mean,
758
00:42:31.159 --> 00:42:35.159
the the happy path of our API is that you
759
00:42:35.239 --> 00:42:39.719
do not get types in your server functions in your
760
00:42:39.840 --> 00:42:45.119
rpcs unless you provide validation that gives you those types.
761
00:42:45.559 --> 00:42:48.159
If you try, like, we don't have a generic API
762
00:42:48.280 --> 00:42:53.440
to just cast the the types coming back with just
763
00:42:53.519 --> 00:42:57.280
typescript because we we think it's unsafe. So that is
764
00:42:57.320 --> 00:42:59.880
the happy path. You have to use a ZOD schema
765
00:43:00.079 --> 00:43:04.400
or an archetypes or whatever to to get that validation
766
00:43:04.719 --> 00:43:06.000
and turn it into types.
767
00:43:06.800 --> 00:43:08.840
It's funny how full circle this is going.
768
00:43:09.280 --> 00:43:11.480
And this happens to me a lot, I have to admit,
769
00:43:11.519 --> 00:43:16.960
because of the lookliness. Like the reason that RPC died
770
00:43:17.000 --> 00:43:20.280
in the first place was because it was clunky to
771
00:43:21.440 --> 00:43:23.760
in my opinion, there's many reasons, but part of it
772
00:43:23.840 --> 00:43:27.079
was that it was clunky to define stuff. And like
773
00:43:27.280 --> 00:43:30.199
it's a challenge like graft Tuel going away because you
774
00:43:30.199 --> 00:43:32.239
know you're defining these like.
775
00:43:32.159 --> 00:43:33.079
To define the types.
776
00:43:34.480 --> 00:43:38.599
So people get these Jason APIs and then and the
777
00:43:38.760 --> 00:43:41.199
people did the Jason on APIs and they like, you know,
778
00:43:41.559 --> 00:43:44.079
manage themselves, but it wasn't schema basis through the code
779
00:43:44.079 --> 00:43:44.719
at run time.
780
00:43:45.280 --> 00:43:47.400
And then like but there's a lots of holes there.
781
00:43:47.519 --> 00:43:50.480
So now people have reinforced on types, which obviously again
782
00:43:50.599 --> 00:43:53.000
gets us back to RPC. But like, it's funny the
783
00:43:53.039 --> 00:43:55.159
framework author's side, like let's say like deeper on the
784
00:43:55.239 --> 00:43:57.760
UI frame side, Like say, guys like myself or people
785
00:43:57.800 --> 00:44:00.000
working on React, we're looking at this and we're like, okay, McKenna,
786
00:44:00.639 --> 00:44:04.800
this works nice. It's ergonomic as thing. People can build
787
00:44:05.159 --> 00:44:07.719
stuff on top of it if they need to. But
788
00:44:08.239 --> 00:44:10.119
I have the pieces I need to do what I
789
00:44:10.159 --> 00:44:13.880
need to mechanically, and it's and it's smooth, but then
790
00:44:14.719 --> 00:44:17.000
we we get to a point where we add back
791
00:44:17.159 --> 00:44:20.400
our own friction because of like best practices.
792
00:44:21.360 --> 00:44:23.920
So that's what it was. Kind of kind of like the.
793
00:44:25.000 --> 00:44:27.559
Nice things on the web, that's truism.
794
00:44:28.400 --> 00:44:30.639
So yeah, it's kind of it's kind of interesting because
795
00:44:30.679 --> 00:44:32.360
because like, yeah, I mean, I love, you know, the
796
00:44:32.400 --> 00:44:34.599
standard schema, A big fan of Valabot and all that
797
00:44:34.639 --> 00:44:36.280
kind of stuff, But it's but it was, it's like
798
00:44:36.280 --> 00:44:38.199
one of those things where like the people building UI
799
00:44:38.280 --> 00:44:41.039
frameworks usually maybe the meta frameworks can, but the UI
800
00:44:41.119 --> 00:44:45.039
frameworks can't. Can't generally won't push those kind of things
801
00:44:45.039 --> 00:44:48.039
on you because they're like they're not they're not in
802
00:44:48.079 --> 00:44:50.559
our range of to be enforced because people will have
803
00:44:50.599 --> 00:44:52.159
different opinions, things will change over.
804
00:44:52.039 --> 00:44:55.480
Time, too much opinion coming from right exactly.
805
00:44:55.519 --> 00:44:57.280
So it's like we.
806
00:44:57.199 --> 00:44:59.400
Being a meta framework, then you get to enforce a
807
00:44:59.480 --> 00:45:00.800
little bit more those opinions.
808
00:45:00.920 --> 00:45:04.599
Yeah, it's just tricky because meta frameworks have a shorter
809
00:45:04.800 --> 00:45:06.760
shouldn't theory have a shorter shelf life?
810
00:45:06.519 --> 00:45:07.760
Because of that, Like.
811
00:45:08.239 --> 00:45:09.960
This was always the struggle I had on was work
812
00:45:09.960 --> 00:45:12.039
on all start because I like didn't want to make
813
00:45:12.119 --> 00:45:14.800
meta framework. I just wanted to make a like a
814
00:45:15.000 --> 00:45:17.440
create React app that work on the servers. This kind
815
00:45:17.440 --> 00:45:20.280
of kind of tension is interesting for the science space.
816
00:45:20.960 --> 00:45:23.519
There was something I wanted to say. You said, there's
817
00:45:23.519 --> 00:45:25.280
three things you need for rpcs to come back.
818
00:45:25.920 --> 00:45:30.920
Yeah, I mentioned, I'll said again, maybe it'll jog your memory. Basically,
819
00:45:31.079 --> 00:45:36.239
it was a type for the underlying system to be
820
00:45:36.400 --> 00:45:39.679
typed or type safe that at least a development time.
821
00:45:39.760 --> 00:45:43.400
Otherwise there's no point. So you probably wouldn't do RPC
822
00:45:43.519 --> 00:45:47.920
if you've just got JavaScript, a weight so that you
823
00:45:47.960 --> 00:45:52.679
can quote unquote block until that remote function finishes, and
824
00:45:53.239 --> 00:45:59.599
optionally the compiler slash bundler so that you can automatically
825
00:45:59.679 --> 00:46:02.840
general rate the stub code to do to translate that
826
00:46:02.960 --> 00:46:07.599
function called into you know, do the serializations, send the
827
00:46:07.639 --> 00:46:10.840
message across the wire, do the de serialization on the
828
00:46:10.840 --> 00:46:12.559
other side and back again?
829
00:46:13.119 --> 00:46:16.039
Right yeah, yeah, And you just mentioned it twice because
830
00:46:16.760 --> 00:46:19.320
I said at the beginning I wasn't trying to build RPC.
831
00:46:19.559 --> 00:46:22.360
I think the final piece that access cemented it for
832
00:46:22.480 --> 00:46:27.679
me was the serialization part. Because we don't communicate in
833
00:46:28.039 --> 00:46:30.559
Jason anymore with these you don't.
834
00:46:31.039 --> 00:46:32.760
No, no, no, I think.
835
00:46:32.639 --> 00:46:36.480
You do, don't you the call over the wire is
836
00:46:36.519 --> 00:46:40.079
it Jason or is it something else for server functions?
837
00:46:40.199 --> 00:46:45.440
Yeah, yes, by default, yes it's Jason. Yeah.
838
00:46:45.639 --> 00:46:48.639
See didn't And this is one of the attractive to
839
00:46:48.679 --> 00:46:51.119
be though. Yeah, this is one of the attractive things
840
00:46:51.119 --> 00:46:53.679
for us time because you can trouble sides. So this
841
00:46:53.760 --> 00:46:56.360
is like react love this, we love this, framework has
842
00:46:56.360 --> 00:46:58.079
love this. This is this is where you can go
843
00:46:58.119 --> 00:47:01.519
back and to what framework wanted is. At the exact
844
00:47:01.559 --> 00:47:03.599
same time I was working on this, we were updating
845
00:47:03.599 --> 00:47:07.119
our approach to doing streaming SSR and stuff, and we
846
00:47:07.159 --> 00:47:09.920
were making it faster and more efficient. Like every framework
847
00:47:09.960 --> 00:47:14.039
has their own serializer. Some are publicly available like solid seabo,
848
00:47:15.000 --> 00:47:21.280
Marco's warp nine devalue from spelp, and we were.
849
00:47:21.119 --> 00:47:23.159
Going to need to give a little bit more context
850
00:47:23.280 --> 00:47:25.960
I think. Okay, so to some of our listeners about
851
00:47:26.079 --> 00:47:28.719
why it is that you need this sort of civilization
852
00:47:28.880 --> 00:47:29.920
for SSR.
853
00:47:29.880 --> 00:47:31.239
I think that'll be really useful.
854
00:47:31.519 --> 00:47:32.440
Yeah, okay, sorry.
855
00:47:33.199 --> 00:47:36.000
Basically you're sending HTML, which you're like, okay, that's great,
856
00:47:36.599 --> 00:47:39.800
but the problem is now you have something ASIC so
857
00:47:41.280 --> 00:47:45.239
you can send the HTML in chunks. Let's say, so
858
00:47:45.280 --> 00:47:50.480
you're sending you know yes or it's streaming is basically
859
00:47:50.480 --> 00:47:54.880
the problem. You want to be able to not only
860
00:47:54.920 --> 00:47:58.119
send the HTML markup, but you want to be able
861
00:47:58.119 --> 00:48:01.239
to send the data across and if you wait for
862
00:48:01.280 --> 00:48:03.519
it all to finish, then just send the Jason and
863
00:48:03.559 --> 00:48:05.679
the HTML. Then you show the whole page at the end.
864
00:48:06.199 --> 00:48:09.519
But if you can, if you can send different types
865
00:48:09.559 --> 00:48:13.760
of serialization values, it's possible to send pieces of the
866
00:48:13.800 --> 00:48:16.679
app in parts and then for the client to go, oh,
867
00:48:17.360 --> 00:48:21.000
you serialize a promise, for example, and the client go okay,
868
00:48:21.159 --> 00:48:25.000
I know this data is coming. That's the most fundamental
869
00:48:25.039 --> 00:48:27.360
way of doing it, where we basically describe a promise
870
00:48:27.360 --> 00:48:29.880
over the wire. So when you know it starts hydrating
871
00:48:29.880 --> 00:48:31.480
part of the page and the whole page hasn't loaded
872
00:48:31.519 --> 00:48:34.000
in from the server, we can go okay, treat it
873
00:48:34.000 --> 00:48:36.320
like a client side promise, and we know that what
874
00:48:36.360 --> 00:48:38.920
will end up happening is actually on the same website page.
875
00:48:39.159 --> 00:48:42.599
We'll actually stream that Jason later, but then we'll when
876
00:48:42.599 --> 00:48:44.599
it comes in, we'll fulfill the promise on the client.
877
00:48:45.119 --> 00:48:50.920
So again, just to clarify the need, if I understand correctly,
878
00:48:51.079 --> 00:48:56.159
correct me if I'm wrong. It's it's your HTML intrinsic
879
00:48:56.280 --> 00:49:03.679
is intrinsically streaming. So the HTML protocol, unlike JavaScript, essentially
880
00:49:03.800 --> 00:49:06.440
you can stream it and it will just execute. The
881
00:49:06.559 --> 00:49:09.719
problem I think is the order of things is the
882
00:49:09.719 --> 00:49:14.960
fact that you that HTML streams top to bottom, whereas
883
00:49:15.119 --> 00:49:18.119
you want to be able to stream things and inject
884
00:49:18.119 --> 00:49:22.079
them in the middle of things that have already arrived. Right,
885
00:49:23.519 --> 00:49:26.719
and Tanner has raised his hand again, so interrupt.
886
00:49:26.880 --> 00:49:29.159
I just want to punctuate that and say that it's
887
00:49:29.639 --> 00:49:35.800
it's about order. It's about componentization of these calls to
888
00:49:35.800 --> 00:49:40.000
to say I have something that needs this amount of data,
889
00:49:40.880 --> 00:49:43.079
you know, and you can have multiples of those in
890
00:49:43.119 --> 00:49:46.679
whatever order you want, And inside of those responses you
891
00:49:46.760 --> 00:49:52.559
can have immediate, immediately returned partial parts of those responses
892
00:49:52.599 --> 00:49:55.280
and have some of them be delayed. So it's almost
893
00:49:55.360 --> 00:49:58.440
like you get the same experience inside of HTML where
894
00:49:58.480 --> 00:50:01.920
you can give the important stuff really quickly and delay
895
00:50:01.960 --> 00:50:04.960
the other stuff. You get that same capability within each
896
00:50:05.559 --> 00:50:07.360
request response life cycle.
897
00:50:07.880 --> 00:50:10.039
You can see it in this just just to say that.
898
00:50:10.119 --> 00:50:12.280
The joke that I like to say is that the
899
00:50:12.320 --> 00:50:16.280
big difference between old websites and modern websites is that
900
00:50:16.320 --> 00:50:19.039
we've replaced the single large spinner with a lot of
901
00:50:19.079 --> 00:50:20.199
small spinners.
902
00:50:21.480 --> 00:50:24.840
Yeah, we've been trying to solve that.
903
00:50:24.920 --> 00:50:25.159
I mean.
904
00:50:25.199 --> 00:50:28.199
The challenge is you can see in the shape that
905
00:50:28.320 --> 00:50:30.360
ht amount it self, it's x amount or you know,
906
00:50:30.400 --> 00:50:33.480
it's a markup language. So these things are naturally nested.
907
00:50:33.480 --> 00:50:34.960
You see it in your components. You have components and
908
00:50:34.960 --> 00:50:38.199
components and components and components. So like doing it top
909
00:50:38.239 --> 00:50:40.719
the bottom doesn't even work because the outer component hasn't closed,
910
00:50:40.760 --> 00:50:43.440
you know what I mean, like these envelopes. So what
911
00:50:43.599 --> 00:50:46.920
ends up happening is the trick to the h mell.
912
00:50:46.960 --> 00:50:50.880
Actually isn't that difficult mechanically because you can put it
913
00:50:50.920 --> 00:50:53.079
on the end in something invisible like a template, and
914
00:50:53.159 --> 00:50:57.199
have JavaScript move it back into place as it loads.
915
00:50:57.239 --> 00:50:59.519
The hard part is that is the data. If you
916
00:50:59.519 --> 00:51:02.039
actually want to wake up parts of that page before
917
00:51:02.079 --> 00:51:04.719
it all loads, you need to tell you need like
918
00:51:04.840 --> 00:51:08.159
a placeholder for the data. Essentially, you need to be like, look,
919
00:51:08.199 --> 00:51:10.440
this data will be coming or you know.
920
00:51:10.760 --> 00:51:14.800
And that's a promise and that's a problem or a substream.
921
00:51:15.280 --> 00:51:19.480
Right, So we started serializing well, I mean, and then
922
00:51:19.480 --> 00:51:22.199
there's different types of data right, like data objects, you know,
923
00:51:22.239 --> 00:51:25.639
and different things. So like even stuff like TRPC has
924
00:51:25.679 --> 00:51:29.000
like advanced like super JSON or like advanced data types
925
00:51:29.039 --> 00:51:31.920
you know. And but for us promises, we're the key
926
00:51:32.360 --> 00:51:35.639
for and we realized that we could bring that serialization
927
00:51:36.159 --> 00:51:38.519
not just in our original SSR, but use it in
928
00:51:38.599 --> 00:51:44.920
our server functions, so we could serialize anything, you know, HTML, elements, promises, whatever.
929
00:51:45.280 --> 00:51:48.760
And this meant that because both sides, RPC let both
930
00:51:48.760 --> 00:51:50.760
sides understand and this is in a sense like how
931
00:51:50.760 --> 00:51:53.559
server components work and React because they can go we
932
00:51:53.639 --> 00:51:57.400
have our special jsx on format and we can communicate
933
00:51:57.400 --> 00:51:59.639
both sides, and now we can communicate react components of
934
00:51:59.679 --> 00:52:02.039
the wire. As I said, our needs are a little
935
00:52:02.039 --> 00:52:05.119
bit simpler with like promises and streams, but it works
936
00:52:05.119 --> 00:52:08.199
out kind of similar. We it lets us build on
937
00:52:08.440 --> 00:52:12.159
really powerful capabilities on this because you can say, return
938
00:52:12.239 --> 00:52:15.280
some data with a promise encoded in it, and then
939
00:52:15.320 --> 00:52:17.119
like have the data come back in chunks.
940
00:52:17.119 --> 00:52:17.920
You can make an.
941
00:52:17.760 --> 00:52:20.679
ACYNC iterable and basically return the stream so the server
942
00:52:20.760 --> 00:52:23.719
can just keep on yielding data into your server function.
943
00:52:23.960 --> 00:52:26.639
And you write it literally as like an ACE generator function.
944
00:52:26.679 --> 00:52:28.960
So you write it as a like an acing function,
945
00:52:29.320 --> 00:52:33.519
and it'll our generator word yields and will literally be
946
00:52:33.599 --> 00:52:37.360
yielding from server to client. So there's a lot of
947
00:52:37.400 --> 00:52:39.440
really cool mechanics here.
948
00:52:39.639 --> 00:52:43.519
Do you support that in? I know that Quick supports that.
949
00:52:43.679 --> 00:52:46.000
I know that, or RBC supports that. Do you guys
950
00:52:46.000 --> 00:52:50.840
also support that that the ability to stream a response
951
00:52:50.920 --> 00:52:52.280
from ann RBC?
952
00:52:53.159 --> 00:52:56.480
Yeah, Salades, Yeah, it's in. It's in, Sarah Belle. I
953
00:52:56.480 --> 00:52:58.400
don't know if someone Start handles it the best in
954
00:52:58.400 --> 00:53:01.199
all cases, but the core technology support to it.
955
00:53:01.159 --> 00:53:06.679
So I guess side uh side quest here is we
956
00:53:06.679 --> 00:53:10.880
we and we started out building our own serializer I
957
00:53:10.920 --> 00:53:15.159
did for tansex Start that was had. It was a
958
00:53:15.199 --> 00:53:20.079
little bit lighter than something like sarahvel Or or the
959
00:53:20.119 --> 00:53:23.239
big giant serializer that that can do like re ex
960
00:53:23.280 --> 00:53:27.440
server components and stuff. And there's also super Jason there.
961
00:53:27.519 --> 00:53:29.960
There's even one that the remix team built right for
962
00:53:30.039 --> 00:53:30.760
react about.
963
00:53:30.880 --> 00:53:33.719
Somebody on the chat called it a tool boards.
964
00:53:33.079 --> 00:53:35.400
Cha Jason, Right, Yeah, there's there's a couple of these,
965
00:53:36.639 --> 00:53:39.239
and and I wrote a simple one that would kind
966
00:53:39.239 --> 00:53:43.039
of get to m v P for tansex Start Alpha.
967
00:53:43.159 --> 00:53:46.880
And even even the simple one could serialized promises and
968
00:53:46.960 --> 00:53:51.880
serialized streams. But then we we realized that we want
969
00:53:51.920 --> 00:53:56.039
to do more complex stuff. We've decided to adopt Sarahvell.
970
00:53:58.119 --> 00:54:02.239
I think I told you that, Ryan, right, okay for you.
971
00:54:03.199 --> 00:54:06.000
We so we have one that works for tansax start,
972
00:54:06.039 --> 00:54:11.199
but we're adopting Sarall because is beyond just being able
973
00:54:11.199 --> 00:54:13.880
to stream this stuff. Sarahville has some very unique So.
974
00:54:13.800 --> 00:54:16.519
What is Serville I think I missed explanation.
975
00:54:16.800 --> 00:54:20.440
It's it's the serializer used by SOLODJS use both in
976
00:54:20.480 --> 00:54:22.960
our server rendering and in our server functions. I was
977
00:54:22.960 --> 00:54:27.880
built by Alexis Monselek core team members sologs and yeah.
978
00:54:28.519 --> 00:54:33.599
It's basically serializes stuff over the wire and then de
979
00:54:33.719 --> 00:54:37.920
serialize it. But it's not exactly Jason. It's something else,
980
00:54:39.079 --> 00:54:42.239
like like React doesn't use Jason either. In case people
981
00:54:42.239 --> 00:54:42.719
don't know.
982
00:54:42.840 --> 00:54:43.519
For their.
983
00:54:44.800 --> 00:54:48.400
Responses from server from server components, you.
984
00:54:48.360 --> 00:54:50.199
See a lot of them that have like it's it's
985
00:54:50.239 --> 00:54:54.119
like a superset of Jason that they then encode and
986
00:54:54.159 --> 00:54:57.480
decode special characters, special things.
987
00:54:57.519 --> 00:55:00.320
Look for at the very least, you won't command lines
988
00:55:00.320 --> 00:55:02.760
separate the Jason in order to be able to send
989
00:55:02.800 --> 00:55:07.039
multiple messages and not be kind of stuck on on
990
00:55:07.159 --> 00:55:09.519
not closing the bracket or something.
991
00:55:10.679 --> 00:55:15.199
Is I think Saravel is very unique and really cool
992
00:55:15.239 --> 00:55:21.079
because Saravel does not Servell uses javascripts essentially to stream
993
00:55:21.320 --> 00:55:25.840
like to serialize all of this. Saravel uses JavaScript and
994
00:55:25.920 --> 00:55:28.519
streams it and executes it over the wire, and it
995
00:55:28.639 --> 00:55:32.760
is it's incredible to watch it work. Because even beyond that,
996
00:55:32.840 --> 00:55:39.119
I mean super JC yeah, a little bit. Yes, I
997
00:55:39.119 --> 00:55:40.280
wouldn't want to call it that.
998
00:55:40.159 --> 00:55:41.800
But yeah, I mean there is a bit of that.
999
00:55:42.239 --> 00:55:45.880
And in some cases where the security isn't concerned, he's
1000
00:55:46.079 --> 00:55:49.519
he's been looking at alternate serialization formats so that you
1001
00:55:50.079 --> 00:55:54.760
don't have the evil aspect of it. But yeah, it is,
1002
00:55:54.760 --> 00:55:57.400
it is, there is there's.
1003
00:55:56.440 --> 00:55:58.599
Great power comes great responsibility.
1004
00:55:58.880 --> 00:56:01.360
But I mean the power is incredible because this is
1005
00:56:01.519 --> 00:56:05.360
this is what enables future facing patterns. We've never had
1006
00:56:05.480 --> 00:56:08.679
things like single page apps be able to easily do
1007
00:56:09.239 --> 00:56:13.559
basically picture. You know, people familiar with React query where
1008
00:56:13.599 --> 00:56:16.239
you can like do a mutation and invalidate like a
1009
00:56:16.239 --> 00:56:20.440
couple of queries. What if you can do the mutation
1010
00:56:21.159 --> 00:56:23.079
so send it to the server and have the server
1011
00:56:24.000 --> 00:56:27.280
figure out what the invalidate and then while it's still there.
1012
00:56:27.360 --> 00:56:30.159
Start fetching the data, that data on the server and
1013
00:56:30.199 --> 00:56:32.920
send it back, you know, like return right away from
1014
00:56:32.960 --> 00:56:35.920
your mutation, but then have it streaming back the data
1015
00:56:36.000 --> 00:56:37.760
for like the next page you're going to visit right.
1016
00:56:37.800 --> 00:56:39.280
If you have the knowledge of say like a router,
1017
00:56:39.719 --> 00:56:43.400
and you have this capability of serialization, you can do
1018
00:56:43.800 --> 00:56:45.760
like single flight mutations and stuff.
1019
00:56:45.960 --> 00:56:48.800
Crap is gonna restart because of not.
1020
00:56:48.719 --> 00:56:54.519
Just single mutations, but stream Yeah, for a minute or so,
1021
00:56:54.800 --> 00:57:01.719
I'll be back. It looks like, but you'll yeah, it's
1022
00:57:02.039 --> 00:57:04.320
not that it's single flight mutations doesn't been around forever,
1023
00:57:04.400 --> 00:57:07.519
but I mean that's how the web worked anyway. But
1024
00:57:08.800 --> 00:57:11.159
single flight mutations that are streamed, I think that's the
1025
00:57:11.159 --> 00:57:13.719
most important part of it. It's like as you get
1026
00:57:13.719 --> 00:57:15.719
the response, as you get the requests on the server,
1027
00:57:16.119 --> 00:57:18.800
and you start processing things that need to change, you
1028
00:57:19.039 --> 00:57:22.119
don't again, don't need to wait to know all of
1029
00:57:22.119 --> 00:57:23.920
the changes that are going to happen to send them
1030
00:57:23.920 --> 00:57:27.079
back to the client. You can start processing them and
1031
00:57:27.119 --> 00:57:31.800
shipping them as you find them to the client. That
1032
00:57:31.800 --> 00:57:36.599
that is incredible, so that you know you're in Validation
1033
00:57:36.800 --> 00:57:40.320
from the server can essentially be streamed in as soon
1034
00:57:40.400 --> 00:57:42.239
as you know about it to the client in the
1035
00:57:42.280 --> 00:57:43.039
same request.
1036
00:57:43.880 --> 00:57:46.480
The funny thing, though, is that that kind of goes
1037
00:57:46.559 --> 00:57:51.320
beyond RPC. That's more in the territory of SSR, isn't it.
1038
00:57:51.719 --> 00:57:56.880
No, Because we're still just talking about individual requests an
1039
00:57:57.000 --> 00:58:02.960
RPC for instance, to say, you know, I want to
1040
00:58:02.800 --> 00:58:05.599
go the base query maybe and then or say I
1041
00:58:05.639 --> 00:58:08.159
want to update a user. I want to update a
1042
00:58:08.280 --> 00:58:12.360
user capability. Right, I'm adding a capability to a user,
1043
00:58:12.840 --> 00:58:16.079
and you you go to add that capability on the
1044
00:58:16.119 --> 00:58:20.000
server side, You'll you'll receive that mutation, You'll you'll create
1045
00:58:20.039 --> 00:58:22.039
that mutation, and then you're probably going to have a
1046
00:58:22.079 --> 00:58:25.119
bunch of other things that need to be invalidated for
1047
00:58:25.199 --> 00:58:27.880
the user or refresh or streams to the user that
1048
00:58:27.920 --> 00:58:30.639
are going to be new. With that new capability, they'll
1049
00:58:30.639 --> 00:58:36.519
gain access to new items, new things, new collection types
1050
00:58:36.559 --> 00:58:40.679
inside of their application, and some of those items might
1051
00:58:40.679 --> 00:58:45.079
take longer for you to fetch on the server and
1052
00:58:45.119 --> 00:58:48.079
give to them than others, So out of the gate,
1053
00:58:48.519 --> 00:58:50.960
you'll want to ship them a new user object that'll
1054
00:58:50.960 --> 00:58:53.000
be really fast, So you ship that down in the
1055
00:58:53.039 --> 00:58:56.719
same response, you push that down, and then you're still
1056
00:58:56.760 --> 00:58:59.880
working on maybe maybe their team data or their work
1057
00:59:00.039 --> 00:59:02.519
based data, and then as you get those, you ship
1058
00:59:02.599 --> 00:59:06.039
those down as well, and so you can start in
1059
00:59:06.079 --> 00:59:10.360
the same request of just a mutation, the response can contain,
1060
00:59:10.840 --> 00:59:15.440
you know, immediate and streamed data. It's really interesting.
1061
00:59:16.079 --> 00:59:17.840
First of all, you're turning on a lot of light
1062
00:59:17.880 --> 00:59:21.400
bulbs for me, so thank you for that, and you're
1063
00:59:21.599 --> 00:59:25.920
raising and it's interesting because what I'm thinking. I'm old
1064
00:59:26.039 --> 00:59:29.760
enough to remember the original RPC implementations back in the
1065
00:59:29.840 --> 00:59:33.880
nineties and one of the main problems with them was
1066
00:59:34.000 --> 00:59:40.840
the fact that they were built as being synchronous type operations,
1067
00:59:41.519 --> 00:59:45.360
and because the assumption was that it is kind of
1068
00:59:45.480 --> 00:59:50.199
like a function and function calls usually are cheap, so
1069
00:59:50.519 --> 00:59:53.320
you can make one function call for the fast stuff
1070
00:59:53.320 --> 00:59:56.039
and another function called for the for the slow stuff,
1071
00:59:56.159 --> 00:59:59.280
or get the call back or stuff like that, and
1072
00:59:59.679 --> 01:00:02.239
they did I didn't really accommodate for that scenario that
1073
01:00:02.280 --> 01:00:07.800
you're describing, where I'm requesting multiple data items and they
1074
01:00:07.840 --> 01:00:12.039
are available at different at different times, and that I
1075
01:00:12.199 --> 01:00:17.199
can create this kind of a sophisticated staggered response that
1076
01:00:17.599 --> 01:00:20.760
data arrives as soon as it's available, and I don't
1077
01:00:20.760 --> 01:00:23.639
need to make multiple calls in order to get all
1078
01:00:23.639 --> 01:00:27.480
this data. Yeah, I'm giving them mic back to you.
1079
01:00:28.760 --> 01:00:32.440
I think that it even goes He takes that even further.
1080
01:00:32.760 --> 01:00:34.880
Is yes, it works for data that you request you
1081
01:00:34.920 --> 01:00:37.320
may know about, but it also works for data that
1082
01:00:37.440 --> 01:00:40.320
maybe you don't want to know about but needs to
1083
01:00:40.360 --> 01:00:45.000
be sent. Is it leaves room now for this hidden
1084
01:00:45.440 --> 01:00:51.320
layer of meta data, of meta actions or meta code
1085
01:00:51.360 --> 01:00:54.119
that could happen with a request response. So, for example,
1086
01:00:54.840 --> 01:00:58.760
the developer experience that I would want as a developer
1087
01:00:58.960 --> 01:01:02.599
when I say update this user capability, I just want
1088
01:01:02.639 --> 01:01:06.719
to update that user capability. I don't want to I
1089
01:01:06.760 --> 01:01:10.360
don't want to have to be responsible for receiving and
1090
01:01:11.679 --> 01:01:14.360
acting on all of this extra data coming back to
1091
01:01:14.400 --> 01:01:16.280
me though. I just want to trust that it's going
1092
01:01:16.320 --> 01:01:18.400
to work. And so naturally, what do a lot of
1093
01:01:18.440 --> 01:01:19.960
people would say is that say, well, I'm going to
1094
01:01:20.039 --> 01:01:22.559
update this user with a new capability, and then they
1095
01:01:22.599 --> 01:01:25.199
get it back, and what do they expect. They expect
1096
01:01:25.360 --> 01:01:28.840
the response to be a user and the new version
1097
01:01:28.840 --> 01:01:32.239
of the user that has the updated capability. What they're
1098
01:01:32.280 --> 01:01:35.000
not going to expect is to have a bunch of
1099
01:01:35.119 --> 01:01:40.199
other random, you know, data invalidation payloads that they now
1100
01:01:40.239 --> 01:01:43.519
have to handle. So what's nice about something like Sarah
1101
01:01:43.559 --> 01:01:47.199
Bell is that it's it's not just you know, this
1102
01:01:47.440 --> 01:01:50.400
super set of Jason or whatever, but it's the ability
1103
01:01:50.480 --> 01:01:53.880
for even frameworks or middlewares or things in the middle
1104
01:01:53.920 --> 01:01:58.400
of that operation more code can just be sent down
1105
01:01:58.480 --> 01:02:01.800
to the client to execute that the response doesn't even
1106
01:02:01.840 --> 01:02:06.000
need to handle or know about. So it leaves a
1107
01:02:06.039 --> 01:02:10.960
lot of room for optimizations and frameworks to get into
1108
01:02:11.000 --> 01:02:14.519
this request response life cycle, but still keep the developer
1109
01:02:14.599 --> 01:02:17.519
developer experience really lean, not.
1110
01:02:17.599 --> 01:02:20.119
Meaning it means, but a little bit scary because if
1111
01:02:20.119 --> 01:02:23.599
I'm understanding correctly what you're saying is, let's say I
1112
01:02:23.679 --> 01:02:28.960
want to get the new user an updated user object
1113
01:02:29.000 --> 01:02:33.400
from the server. So I do an RPC call, I
1114
01:02:33.599 --> 01:02:36.519
get back the new user, and I do with it
1115
01:02:36.639 --> 01:02:39.239
whatever I do with it. But it turns out that
1116
01:02:39.760 --> 01:02:43.119
it also realized that some group that the user belongs
1117
01:02:43.159 --> 01:02:47.400
to updated, so it sends that down as well. I
1118
01:02:47.440 --> 01:02:51.159
don't handle it because I don't expect it, so I
1119
01:02:51.239 --> 01:02:53.559
didn't even write the code to handle it, but it
1120
01:02:53.679 --> 01:02:57.079
also sent the code that will handle it for me.
1121
01:02:57.280 --> 01:02:59.400
If I understand correctly, what you're kind.
1122
01:02:59.199 --> 01:03:02.480
Of it depends. It depends. A lot of this gets
1123
01:03:02.519 --> 01:03:07.159
into how you use such a tool, right, Yes, you
1124
01:03:07.239 --> 01:03:10.079
could stream down the code that handles it as well,
1125
01:03:10.119 --> 01:03:13.480
but more than likely that kind of code would live
1126
01:03:13.519 --> 01:03:16.000
on the client. It would live on the client side.
1127
01:03:16.599 --> 01:03:20.920
To say, we are orchestrating this metadata layer right as
1128
01:03:20.960 --> 01:03:23.719
the client. We know that we're going to want this
1129
01:03:23.840 --> 01:03:25.760
extra metadata to invalidate.
1130
01:03:25.880 --> 01:03:28.239
So it's a callback that I attached that one, or
1131
01:03:28.280 --> 01:03:31.679
middleware that I attach that gets invoked with the extra
1132
01:03:31.840 --> 01:03:36.039
data that happened to arrive on because of some other
1133
01:03:36.199 --> 01:03:37.880
call that caused it to be sent.
1134
01:03:38.159 --> 01:03:41.039
And we're talking about middleware that can span the client
1135
01:03:41.079 --> 01:03:43.440
and the server just like a server function. Right, it's
1136
01:03:43.480 --> 01:03:48.639
middleware that can compose together inside of this system that's
1137
01:03:48.719 --> 01:03:52.599
extracting into client and server and creating. It's RPC middleware
1138
01:03:52.880 --> 01:03:53.519
essentially what.
1139
01:03:53.480 --> 01:03:57.679
It is, correct, I'm trying to think of an actual
1140
01:03:57.960 --> 01:04:02.960
valid scenario and you tell me if it kind of matches.
1141
01:04:03.679 --> 01:04:07.280
So I know that a lot of times as secure
1142
01:04:07.320 --> 01:04:12.360
systems have this concept of a refresh token. So if
1143
01:04:12.440 --> 01:04:16.599
your access token in validates, you have a refresh stoken
1144
01:04:16.639 --> 01:04:19.559
that generates a new access token for you, and that
1145
01:04:19.760 --> 01:04:22.320
happens behind the scenes. You don't need to be aware
1146
01:04:22.360 --> 01:04:25.239
of this whole thing or this whole mechanism going on.
1147
01:04:25.360 --> 01:04:27.719
So is it something kind of like that.
1148
01:04:27.960 --> 01:04:30.480
I don't know if I would use this for that.
1149
01:04:31.360 --> 01:04:34.719
I mean you could, No, I'm just thinking about the
1150
01:04:34.840 --> 01:04:39.840
scenario where you're making a function call for a but
1151
01:04:40.000 --> 01:04:43.320
that triggers also other stuff to take place in the
1152
01:04:43.400 --> 01:04:46.679
system that you may not necessarily be aware of.
1153
01:04:47.000 --> 01:04:50.800
Yeah. I think what we're mostly talking about here is optimizations, right,
1154
01:04:50.920 --> 01:04:53.440
kind of like the example that Ryan brought up is
1155
01:04:53.440 --> 01:04:58.159
like you send off pre crashing. Yeah, you send off
1156
01:04:58.159 --> 01:05:01.440
a request with a mutation and the intent is known
1157
01:05:01.480 --> 01:05:04.440
that you're going to be at this destination next. Instead
1158
01:05:04.480 --> 01:05:08.440
of waiting for all of this to to settle, the
1159
01:05:08.519 --> 01:05:10.840
dust to settle before you go request the assets for
1160
01:05:10.920 --> 01:05:13.719
your next destination, you can do all of this in
1161
01:05:13.760 --> 01:05:17.039
one request. You can send all of the assets that
1162
01:05:17.079 --> 01:05:19.159
are going to be requested anyway.
1163
01:05:19.239 --> 01:05:21.559
Yeah, it's it's kind of interesting.
1164
01:05:21.199 --> 01:05:23.079
Kind of resource sense in a sense.
1165
01:05:23.920 --> 01:05:24.159
Yeah.
1166
01:05:24.320 --> 01:05:27.559
What I found kind of interesting about this resource.
1167
01:05:27.159 --> 01:05:29.000
Pushing resource pushing.
1168
01:05:29.079 --> 01:05:32.440
Yeah, when I when I was working on the solution,
1169
01:05:32.719 --> 01:05:35.079
was the kind of that realization is that people are
1170
01:05:35.079 --> 01:05:38.639
already writing their code mostly isomorphically, which means that like
1171
01:05:38.679 --> 01:05:42.800
they're already creating these patterns. So like running the say
1172
01:05:42.800 --> 01:05:46.920
the routeloaders again on the server and a mutation and
1173
01:05:47.000 --> 01:05:50.119
then expecting the code to be basically the same on
1174
01:05:50.199 --> 01:05:53.320
the client because it is the same code it's source
1175
01:05:53.400 --> 01:05:57.000
code basically gives you this ability. So like what was
1176
01:05:57.039 --> 01:05:59.960
kind of cool is yeah, the kind of optimization look
1177
01:06:00.079 --> 01:06:02.599
you can go in because if you're in a nested route,
1178
01:06:02.599 --> 01:06:04.519
if you're familiar with nest to routing, maybe the top
1179
01:06:04.559 --> 01:06:08.199
section doesn't change, only the like the two sections underneath
1180
01:06:08.280 --> 01:06:10.480
swap on this navigation, so you're like you're staying on
1181
01:06:10.480 --> 01:06:12.280
the same main page and then you go to the
1182
01:06:12.280 --> 01:06:14.840
next page. Well, if that data from the top main
1183
01:06:14.880 --> 01:06:17.559
page isn't being updated, then you don't have to fetch
1184
01:06:17.559 --> 01:06:20.480
it again on the server loaders. Like basically we were
1185
01:06:20.679 --> 01:06:24.519
able to use the same sort of knowledge of what
1186
01:06:24.679 --> 01:06:28.559
route changes and what data is already available based on
1187
01:06:29.039 --> 01:06:34.920
what things it would fetch when it navigates to those pages,
1188
01:06:35.480 --> 01:06:38.599
to the point that we basically go, Okay, this is
1189
01:06:38.639 --> 01:06:40.440
already there and the client don't need the updated and
1190
01:06:40.480 --> 01:06:43.440
it hasn't explicitly invalidated. This is already there, this is new,
1191
01:06:43.800 --> 01:06:46.880
this isn't just on this page, this has been updated.
1192
01:06:46.960 --> 01:06:50.679
And then fetch those things and put them on that request.
1193
01:06:50.760 --> 01:06:52.960
But the client are the server responds right away. So
1194
01:06:53.000 --> 01:06:55.320
the server goes, okay, we're going to redract to this
1195
01:06:55.400 --> 01:06:58.440
next page, and the client goes, okay, I'm going to
1196
01:06:58.480 --> 01:07:00.920
go to this next page. So the client goes to
1197
01:07:00.960 --> 01:07:04.280
that next page. But because those promise stubs are there,
1198
01:07:05.519 --> 01:07:07.400
when it goes to load the data, it goes, oh, no,
1199
01:07:07.480 --> 01:07:10.960
promise stub right here, it's already in the cash. I'm
1200
01:07:10.960 --> 01:07:13.360
going to use this promise instead of fetching it again
1201
01:07:14.119 --> 01:07:17.000
for the stuff that's new. So it's it's kind of
1202
01:07:17.719 --> 01:07:20.199
it's weird how you can kind of like do this
1203
01:07:20.280 --> 01:07:23.239
kind of predictively, but in the end, what you end
1204
01:07:23.320 --> 01:07:25.199
up with, which is my favorite part about this, is
1205
01:07:25.559 --> 01:07:28.119
you're actually leveraging your knowledge of the client side cash
1206
01:07:28.119 --> 01:07:31.159
on the server here, so you actually don't need cashing
1207
01:07:31.280 --> 01:07:34.360
on the server in this mechanism. Like you could still
1208
01:07:34.400 --> 01:07:36.360
optimize it with like a rettis or something, but we
1209
01:07:36.760 --> 01:07:39.719
never went through that whole Next DS use cash dilemma
1210
01:07:40.039 --> 01:07:42.840
or cash stup because when you do server functions, you
1211
01:07:42.880 --> 01:07:44.519
re render the whole page. It's kind of like remix.
1212
01:07:44.559 --> 01:07:47.199
It's like that loader bit. You know the whole route sections.
1213
01:07:47.320 --> 01:07:49.239
So when you hit a you have five data points, well,
1214
01:07:49.239 --> 01:07:51.719
guess what, you are fetching all five data points.
1215
01:07:51.719 --> 01:07:54.920
There's no way for you to separate those apart.
1216
01:07:54.679 --> 01:07:56.280
Which means that if you don't want to refetch all
1217
01:07:56.320 --> 01:07:58.679
five data points every single time, you are going to
1218
01:07:58.719 --> 01:08:01.320
cash them on the server. This approach you'll let you
1219
01:08:01.400 --> 01:08:04.559
basically use the knowledge of the route and the knowledge
1220
01:08:04.559 --> 01:08:07.840
of the invalidation from the mutation to actually only fetch
1221
01:08:07.840 --> 01:08:11.159
what's needed, so server cashes aren't necessary. It feels like
1222
01:08:11.159 --> 01:08:12.760
a single page app word. You know, the cache is
1223
01:08:12.840 --> 01:08:15.960
on the client, but it's actually doing this all in
1224
01:08:15.960 --> 01:08:16.680
a single.
1225
01:08:16.880 --> 01:08:20.199
So again, let me see if I'm getting this, because
1226
01:08:21.079 --> 01:08:23.560
to an extent, it's kind of incidental to the fact
1227
01:08:23.560 --> 01:08:27.680
that it's RPC. It's basically the fact that you're controlling
1228
01:08:28.439 --> 01:08:31.479
both sides and the protocol that lets you do a
1229
01:08:31.520 --> 01:08:34.239
lot of magic. The fact that it's RPC, like I said,
1230
01:08:34.239 --> 01:08:38.439
it's almost incidental. It might have been some other mechanism.
1231
01:08:39.279 --> 01:08:40.720
But what you're.
1232
01:08:40.640 --> 01:08:44.880
Saying is this, I'm triggering an operation to receive data.
1233
01:08:45.920 --> 01:08:59.159
I know that this operation will likely trigger redirection or
1234
01:08:59.479 --> 01:09:06.600
transition to another page. I can prefetch or push more accurately.
1235
01:09:06.680 --> 01:09:09.920
I can like you said tenor I use the wrong analogy,
1236
01:09:09.960 --> 01:09:13.359
because it's not client instigated, its server instigated. The server
1237
01:09:13.560 --> 01:09:18.039
side knows that I'm likely going to be needing that
1238
01:09:18.159 --> 01:09:23.479
additional data. I can send it down, hold it somewhere
1239
01:09:23.479 --> 01:09:27.039
in the client side so that when I actually needed
1240
01:09:27.159 --> 01:09:28.119
it's already there.
1241
01:09:28.760 --> 01:09:33.640
Basically, and that becomes even more powerful as you stream,
1242
01:09:34.399 --> 01:09:37.680
because we could do this before with single flight mutation.
1243
01:09:37.800 --> 01:09:41.079
As you send it, and if you spend enough time
1244
01:09:41.119 --> 01:09:43.560
on the server, you can gather up all of the
1245
01:09:43.640 --> 01:09:46.840
data and finally send it all back and then allow
1246
01:09:46.880 --> 01:09:51.920
the user to navigate. But streaming allows you to respond immediately,
1247
01:09:52.640 --> 01:09:57.039
but tick off those requests server side and then stream
1248
01:09:57.079 --> 01:10:01.840
them down to the user and utilize utilize that connection
1249
01:10:01.920 --> 01:10:02.800
that's already open.
1250
01:10:02.920 --> 01:10:06.439
It's because the frameworks support a signatively. Things like suspense
1251
01:10:07.119 --> 01:10:10.479
basically will trigger and treat your cached promise or your
1252
01:10:10.720 --> 01:10:13.720
pre pushed promise, and a new promise would fetch identically.
1253
01:10:14.119 --> 01:10:17.880
So in these kind of scenarios, you actually get further ahead.
1254
01:10:18.000 --> 01:10:20.760
You can start rendering the next page before that data
1255
01:10:20.920 --> 01:10:21.560
has arrived.
1256
01:10:22.960 --> 01:10:26.319
And the fact that we're componentized kind of necessitates this
1257
01:10:26.399 --> 01:10:29.640
whole thing because otherwise one of the big problems with
1258
01:10:30.159 --> 01:10:35.439
components is that in capsulation, if you're following through on
1259
01:10:35.479 --> 01:10:41.479
it often leads to waterfalls. So the fact and react
1260
01:10:41.520 --> 01:10:44.560
query it back of the day at the time was
1261
01:10:44.840 --> 01:10:49.439
so great in this regard because you fetched from one
1262
01:10:49.479 --> 01:10:52.920
component and then it got reused the data in other
1263
01:10:53.000 --> 01:10:59.039
components without you needing to like break in capsulation be
1264
01:10:59.279 --> 01:11:03.000
very iplicit about it. It was totally implicit. So now
1265
01:11:03.000 --> 01:11:05.520
you're kind of taking it to the next level in
1266
01:11:05.560 --> 01:11:07.720
a sense this and this.
1267
01:11:08.000 --> 01:11:10.439
Opens up new can of worms. I don't know how
1268
01:11:10.439 --> 01:11:12.720
deeply you want to get into that, but components have
1269
01:11:12.800 --> 01:11:17.399
you on again component level data fetching it. I'm still
1270
01:11:18.319 --> 01:11:21.640
I think it's still really the way to go. And
1271
01:11:21.680 --> 01:11:27.199
then thinking about thinking about the the optimizations that need
1272
01:11:27.279 --> 01:11:30.800
to be made at the routing level and the SEO
1273
01:11:30.960 --> 01:11:33.479
level and the page levels to get rid of waterfalls,
1274
01:11:33.479 --> 01:11:36.880
and that you know these are optimizations and making those
1275
01:11:36.880 --> 01:11:41.359
optimizations as easy as we can is really important, and
1276
01:11:41.439 --> 01:11:45.159
we can do that through API design with our routing.
1277
01:11:45.359 --> 01:11:48.960
We could do it through compilers like relay, but they
1278
01:11:49.039 --> 01:11:52.760
are optimizations. I think at that point, I like this,
1279
01:11:53.279 --> 01:11:55.039
I like everything that we've talked about is really.
1280
01:11:55.119 --> 01:11:57.439
I interrupt you again because I have to say that
1281
01:11:57.600 --> 01:12:00.760
one of the biggest downfalls of RP see back in
1282
01:12:00.800 --> 01:12:03.760
the old days, and one that I was so concerned
1283
01:12:03.800 --> 01:12:06.760
with that I actually at the end of my presentation
1284
01:12:06.920 --> 01:12:10.319
or RPC, I talk about the potential downsides of RPC,
1285
01:12:10.439 --> 01:12:13.520
and it's one of the items listed there is the
1286
01:12:13.560 --> 01:12:20.000
fact that RPC kind of encourages waterfalls because you make
1287
01:12:20.039 --> 01:12:22.760
a function call to get some data, and then you
1288
01:12:22.840 --> 01:12:25.880
make another function call to get some more data, and
1289
01:12:25.960 --> 01:12:28.520
another function called to get some more data, so you
1290
01:12:28.640 --> 01:12:34.319
end up with chatty protocols and waterfalls because the implicit
1291
01:12:34.359 --> 01:12:37.479
assumption is that it works like functions and functions are cheap.
1292
01:12:38.479 --> 01:12:43.199
And what you're saying is that you're overcoming it by
1293
01:12:43.439 --> 01:12:47.359
being smart realizing you know, you can still write it
1294
01:12:47.039 --> 01:12:51.800
like it is if it's a waterfall, but you've triggered
1295
01:12:51.840 --> 01:12:55.039
the requests, the generation of the code that's going to
1296
01:12:55.079 --> 01:12:58.399
be requested in the third request, in the first request,
1297
01:12:58.600 --> 01:13:02.439
and already be even scented down, so by the time
1298
01:13:02.520 --> 01:13:06.479
I get to that third RPC call, it's returning immediately
1299
01:13:06.600 --> 01:13:08.359
because all the data is already there.
1300
01:13:08.520 --> 01:13:12.800
Yeah, we're getting into what I would call orchestration of
1301
01:13:12.880 --> 01:13:17.600
our PC, like RPC orchestration because and I think that
1302
01:13:18.399 --> 01:13:21.640
you know, single flight mutations is one kind of flavor
1303
01:13:22.119 --> 01:13:25.920
of utilizing rpcs and orchestrating like data flow through rpcs.
1304
01:13:26.279 --> 01:13:31.760
There's other ones like routing is a big RPC orchestrator really,
1305
01:13:31.760 --> 01:13:35.039
anything that's providing life cycle based on user input, so
1306
01:13:35.359 --> 01:13:37.520
even forms or the framework itself.
1307
01:13:37.520 --> 01:13:43.880
It's it's tricky because the biggest cause of waterfalls, in
1308
01:13:43.920 --> 01:13:48.840
my opinion, in terms of co location is often those
1309
01:13:48.880 --> 01:13:52.119
two causes. There's the code splitting. We want to code
1310
01:13:52.159 --> 01:13:54.920
split at the route level generally, like you know, you
1311
01:13:54.920 --> 01:13:57.520
can do lazy components wherever, but because of the code splitting,
1312
01:13:58.279 --> 01:14:01.000
it's hard to fetch the day before you have the
1313
01:14:01.039 --> 01:14:04.439
code to pitch the data essentially, So that's what pushes
1314
01:14:04.479 --> 01:14:07.239
us to hoisting. And it's necessary because you don't want
1315
01:14:07.239 --> 01:14:08.600
to load all the JABSKO for your whole app.
1316
01:14:08.640 --> 01:14:11.960
But if you didn't, if.
1317
01:14:11.840 --> 01:14:16.199
You didn't actually do that, then the other second thing
1318
01:14:16.239 --> 01:14:20.039
you hit on the client. Is that co location of
1319
01:14:20.159 --> 01:14:24.000
UI and components can lead to waterfalls depending on how
1320
01:14:24.079 --> 01:14:27.560
the renderer handles the ACYNC in the in the rendering.
1321
01:14:27.680 --> 01:14:30.439
So like, for example, let's say every time you hit
1322
01:14:30.479 --> 01:14:32.880
a promise, you throw and it then re renders the
1323
01:14:32.880 --> 01:14:35.039
whole thing. Well, if there's a promise after that, well
1324
01:14:35.399 --> 01:14:37.199
then you're causing a waterfall, right.
1325
01:14:37.119 --> 01:14:40.560
And I'm saying that because RPC potentially brings in the
1326
01:14:40.640 --> 01:14:44.680
third cause, which is just the fact that people can
1327
01:14:45.239 --> 01:14:48.119
look at the code think that if it looks like
1328
01:14:48.199 --> 01:14:51.279
a function, then it is a function, and just write
1329
01:14:51.279 --> 01:14:54.800
the code in a way that's very inefficient and generates
1330
01:14:54.800 --> 01:14:57.479
a waterfall regardless of the framework.
1331
01:14:57.520 --> 01:15:00.239
Right right, which is which is well, I mean there's
1332
01:15:00.239 --> 01:15:04.239
two different types of waterfalls, necessary waterfalls and unnecessari stary waterfalls.
1333
01:15:04.239 --> 01:15:08.239
Necessary waterfalls can still be made unnecessary if you say,
1334
01:15:08.359 --> 01:15:10.239
move everything into a single function call and you know,
1335
01:15:10.319 --> 01:15:11.319
put them together whatever.
1336
01:15:11.560 --> 01:15:13.119
But there's a dependency.
1337
01:15:13.199 --> 01:15:15.840
But there's a dependency, right, Like there's like you need
1338
01:15:15.880 --> 01:15:18.600
to get the users to get or get the user
1339
01:15:18.640 --> 01:15:20.399
to get the posts for some reason. But if you
1340
01:15:20.399 --> 01:15:22.479
could fetch them both off the user ID, like the
1341
01:15:22.520 --> 01:15:24.640
poster is user ID and the user information off use ID,
1342
01:15:24.760 --> 01:15:27.399
then that's an unnecessary waterfall. The problem is we cause
1343
01:15:27.479 --> 01:15:31.960
unnecessary waterfalls all the time in our UI rendering. If
1344
01:15:32.079 --> 01:15:35.159
if because we go okay, well the posts go under
1345
01:15:35.199 --> 01:15:39.319
the user section, and then you you basically by by
1346
01:15:39.520 --> 01:15:41.479
using ACYNC in your component, you're basically like putting in
1347
01:15:41.479 --> 01:15:44.039
a weight in the middle and blocking. Blocking rendering sucks
1348
01:15:44.039 --> 01:15:48.399
a weights suck for rendering UI. You don't want ACYNC
1349
01:15:48.399 --> 01:15:51.880
components really it React gets away with it on the
1350
01:15:51.880 --> 01:15:54.640
server because it's on the server, and server waterfalls are
1351
01:15:54.680 --> 01:15:55.479
not as bad.
1352
01:15:55.520 --> 01:15:56.880
But I'd argue against that.
1353
01:15:56.920 --> 01:16:00.159
I'm generally speaking it's this co location of data and
1354
01:16:00.319 --> 01:16:04.199
UI that causes this blocking. The reason I'm stressing on
1355
01:16:04.239 --> 01:16:08.760
this is because it's solvable with signals, Like basically, if
1356
01:16:08.840 --> 01:16:11.880
you're doing fine green rendering, there's no reason to await
1357
01:16:12.079 --> 01:16:14.439
or block except for where the data is finally being
1358
01:16:14.520 --> 01:16:16.960
used at the end of the data chain, which means
1359
01:16:16.960 --> 01:16:21.399
that you could parallelize this data fetching for unnecessary waterfalls
1360
01:16:21.680 --> 01:16:27.479
not only for like sibling components, but also nested components.
1361
01:16:27.520 --> 01:16:30.720
Because the component aspect doesn't matter, you're not blocking to
1362
01:16:30.760 --> 01:16:34.960
re render the the you know this component, you're literally
1363
01:16:35.079 --> 01:16:37.279
just going, oh, I actually need this in this text,
1364
01:16:37.279 --> 01:16:40.800
in this div I'm going to block there and everything beside.
1365
01:16:40.840 --> 01:16:44.079
It's a sibling. You basically turn all you flatten the
1366
01:16:44.079 --> 01:16:44.600
whole tree.
1367
01:16:44.760 --> 01:16:46.640
And this is something you know, just to be clear,
1368
01:16:47.000 --> 01:16:51.880
just you do all this magic for us automatically, right,
1369
01:16:52.159 --> 01:16:53.439
It's not something.
1370
01:16:53.880 --> 01:16:56.920
I mean, this is run to time what I'm talking about.
1371
01:16:56.960 --> 01:16:58.640
The funniest thing is it's not actually magic. It's just
1372
01:16:58.680 --> 01:17:02.119
the way signals work. This is something that I kind
1373
01:17:02.159 --> 01:17:03.800
of discovered a while ago when I was doing fine
1374
01:17:03.800 --> 01:17:08.760
green rendering. That pine green rendering is actually it flattens
1375
01:17:08.760 --> 01:17:11.199
the tree. That basically what does there's no components anymore.
1376
01:17:11.239 --> 01:17:13.520
You just have a bunch of independent things. So if
1377
01:17:13.520 --> 01:17:14.119
you fly on the.
1378
01:17:14.039 --> 01:17:18.479
Tree, because signals don't care about component boundaries essentially.
1379
01:17:18.039 --> 01:17:20.039
So if you fly in the tree and talk about
1380
01:17:20.279 --> 01:17:23.479
async that way, then it's the same thing. Nothing has
1381
01:17:23.520 --> 01:17:26.119
to block unless it actually has a data dependency on itself.
1382
01:17:26.159 --> 01:17:30.199
So necessary waterfalls still walk, but things that are not
1383
01:17:30.279 --> 01:17:33.479
necessary waterfalls don't need to block. So I think this
1384
01:17:33.640 --> 01:17:36.560
is another wind that you're going to see in the
1385
01:17:36.560 --> 01:17:39.600
signal of libraries. So people haven't really been leveraging this yet,
1386
01:17:39.760 --> 01:17:43.359
but it's coming soon and we know what it looks like.
1387
01:17:43.600 --> 01:17:45.039
Right, So I'm going to jump in here because we're
1388
01:17:45.079 --> 01:17:47.800
running a little long here on time, and I have
1389
01:17:47.840 --> 01:17:50.239
a suspicion with anything that Dan gets into. We could
1390
01:17:50.239 --> 01:17:53.760
talk to for two or three hours when he gets
1391
01:17:53.800 --> 01:17:56.520
into a topic. So before we wrap up and head
1392
01:17:56.520 --> 01:18:01.399
to picks, is there any last word on our PCs?
1393
01:18:01.800 --> 01:18:02.279
In summary?
1394
01:18:02.319 --> 01:18:04.800
And all I can say is my summary is that
1395
01:18:04.840 --> 01:18:08.439
we absolutely positively need to get Ryan and Tanner on
1396
01:18:08.720 --> 01:18:12.000
to continue this conversation because we are scratching the surface.
1397
01:18:12.039 --> 01:18:12.720
It feels to me.
1398
01:18:12.920 --> 01:18:15.960
Yeah, I mean, even just what Ryan brought up about,
1399
01:18:16.000 --> 01:18:20.920
like all the ACYNC signal stuff, there's a lot that
1400
01:18:20.960 --> 01:18:21.600
we could go into.
1401
01:18:21.680 --> 01:18:24.199
Yeah, but then stuck is built on react. What does
1402
01:18:24.239 --> 01:18:25.960
that have to do with the sink signals?
1403
01:18:26.359 --> 01:18:28.439
Maybe you say something about that, let's say, let's say
1404
01:18:28.479 --> 01:18:31.600
it for later, Let's save that for later. We are
1405
01:18:31.680 --> 01:18:35.119
running along. There's a lot to talk about. But and
1406
01:18:35.199 --> 01:18:37.279
you know, hold on, you brought up a good point
1407
01:18:37.279 --> 01:18:43.800
though about the necessary waterfalls as well, Like necessary waterfalls
1408
01:18:43.800 --> 01:18:45.720
are still there and they still need to be handled,
1409
01:18:46.199 --> 01:18:48.560
And like I feel like I've been spending a lot
1410
01:18:48.560 --> 01:18:51.159
of time on that as well as like, you can
1411
01:18:51.199 --> 01:18:54.840
still make mistakes there that you can't solve with a
1412
01:18:54.880 --> 01:18:57.760
bundler or you can't solve with with signals or anything
1413
01:18:57.760 --> 01:19:00.239
like that. So but you can solve some of those
1414
01:19:00.239 --> 01:19:04.680
problems with with good API design and prefetching and and
1415
01:19:04.720 --> 01:19:06.840
you know, so, I think there's a lot more to
1416
01:19:06.960 --> 01:19:11.119
unpack there. I don't really want to. Okay, there's a
1417
01:19:11.159 --> 01:19:16.600
reason that tan Stack everything is built to be agnostic.
1418
01:19:17.119 --> 01:19:20.359
I'm a very firm believer and React and obviously it's
1419
01:19:20.399 --> 01:19:24.600
it's our most supportive framework, but it by no means perfect.
1420
01:19:24.760 --> 01:19:29.159
It's it's not, it's but it's amazing, it's great. There
1421
01:19:29.319 --> 01:19:32.800
there's pros and cons to every UI framework, but I
1422
01:19:33.119 --> 01:19:38.560
I'm very much preparing for a future where there are bigger,
1423
01:19:38.720 --> 01:19:44.520
better UI frameworks doing amazing things. And the things that
1424
01:19:44.680 --> 01:19:48.319
Ryan just teased and talking about with like signals and
1425
01:19:48.399 --> 01:19:53.479
acinc and flattening signals to to you know, around suspense
1426
01:19:53.560 --> 01:19:58.520
and things like that, that stuff's really exciting. Uh I.
1427
01:19:58.560 --> 01:20:00.399
And I'm just gonna gush a little bit right here
1428
01:20:00.439 --> 01:20:03.359
before we end and say that the things that Ryan
1429
01:20:03.600 --> 01:20:06.840
is working on with solid two point zero have made
1430
01:20:06.840 --> 01:20:10.439
me the most excited about what's technically possible with the
1431
01:20:10.560 --> 01:20:15.880
UI framework since I discovered React and discovered hooks and
1432
01:20:16.359 --> 01:20:19.079
really got into it. So hopefully it's a good teaser
1433
01:20:19.159 --> 01:20:21.000
for maybe what we can talk about next time.
1434
01:20:21.119 --> 01:20:25.920
Thank you, look, I'm here for it each and every
1435
01:20:25.920 --> 01:20:28.279
time you just say when I'll have you on the
1436
01:20:28.319 --> 01:20:28.840
show again.
1437
01:20:29.000 --> 01:20:32.760
Alrighty well, thanks to Ryan and Tanner for scratching the
1438
01:20:32.760 --> 01:20:37.479
surface on our PCs and waiting our whistle for more
1439
01:20:37.479 --> 01:20:40.199
discussion on the truly geeky stuff that we talk about.
1440
01:20:41.399 --> 01:20:43.399
With that, we'll move to picks picture, the part of
1441
01:20:43.439 --> 01:20:45.800
the show where we get to talk about anything we
1442
01:20:45.840 --> 01:20:47.840
want to talk about, could be tech related, could be
1443
01:20:47.880 --> 01:20:52.880
not tech related. We run the gamut. I will start
1444
01:20:52.880 --> 01:20:55.439
off with what I consider the high point of any
1445
01:20:55.439 --> 01:20:57.640
of our episodes, which is the dad jokes of the week.
1446
01:20:58.800 --> 01:21:00.960
So the other day I was watching a show called
1447
01:21:01.000 --> 01:21:03.760
ten Ways to Avoid a Shark attack, and I was
1448
01:21:03.800 --> 01:21:06.359
surprised that stay out of the water wasn't on the list.
1449
01:21:06.520 --> 01:21:11.279
There was actually a skit about that on YouTube where
1450
01:21:11.680 --> 01:21:15.279
they do a parody of a horror movie when there's
1451
01:21:15.359 --> 01:21:18.399
the shark in the pool, and everybody's like, oh my god,
1452
01:21:18.439 --> 01:21:19.560
there's a shark in the pool.
1453
01:21:19.600 --> 01:21:20.359
What can we do in this?
1454
01:21:20.479 --> 01:21:22.239
The one guy keeps on saying.
1455
01:21:22.479 --> 01:21:25.359
Just don't go into the pool, right right.
1456
01:21:25.439 --> 01:21:29.880
So yeah, my drum joke here is not working. And
1457
01:21:29.920 --> 01:21:32.600
I'm really bummed because that adds all the impact. So
1458
01:21:32.760 --> 01:21:35.760
I'm gonna have to sue a riverside for that one.
1459
01:21:36.319 --> 01:21:39.640
So my wife looked at my feet this morning and said, honey,
1460
01:21:39.640 --> 01:21:41.720
your socks don't match. And I said, that's funny. I
1461
01:21:41.720 --> 01:21:43.399
have another pair just like them in the drawer. But
1462
01:21:43.520 --> 01:21:47.760
it boom. And then finally, in a surprising announcement, Head
1463
01:21:47.800 --> 01:21:52.279
Shoulders have decided to discontinue their popular anti dandruff shampoo line.
1464
01:21:52.359 --> 01:21:55.359
The decision left many people scratching their heads. I expected
1465
01:21:55.840 --> 01:21:57.880
not that I need that, as you can tell by
1466
01:21:57.920 --> 01:22:01.159
the video. So those are the dad jokes of the week. Dan,
1467
01:22:01.399 --> 01:22:02.600
you got any picks for us?
1468
01:22:03.079 --> 01:22:05.479
Yeah? So two funny things.
1469
01:22:06.000 --> 01:22:08.920
First of all, Avishai Shalom, we've had on this show
1470
01:22:09.079 --> 01:22:13.039
a while back, made an interesting observation on X and
1471
01:22:13.079 --> 01:22:15.920
I literally quote him because he just wrote it very well.
1472
01:22:16.319 --> 01:22:19.720
He was talking about the fact that will Ai destroy
1473
01:22:19.800 --> 01:22:24.960
the Worldwide Web because the bit it's destroying the web's
1474
01:22:25.039 --> 01:22:29.399
business model, and he says it's actually worse. NLM's marked
1475
01:22:29.399 --> 01:22:32.720
the end of open networks because the cost of producing
1476
01:22:32.880 --> 01:22:37.399
junk and malicious content is now near zero. We already
1477
01:22:37.479 --> 01:22:41.239
see this in LinkedIn, Facebook, et cetera, but more alarming
1478
01:22:41.359 --> 01:22:46.239
in GitHub and NPM. And it's a very interesting observation,
1479
01:22:46.359 --> 01:22:49.680
I think, And so that would be my first pick,
1480
01:22:49.720 --> 01:22:52.680
that observation. And the second one is this funny story
1481
01:22:52.680 --> 01:22:56.039
that just came out about the fact that the UK
1482
01:22:56.239 --> 01:22:59.840
government is trying to sue four Chan. Turns out that
1483
01:22:59.880 --> 01:23:04.079
the the UK passed the law that requires age verification
1484
01:23:04.760 --> 01:23:11.000
before you access potentially offensive content, and four Chan, being
1485
01:23:11.039 --> 01:23:16.000
an American company, is not complying with the UK laws,
1486
01:23:16.319 --> 01:23:21.279
so they're actually trying to force them to comply by
1487
01:23:21.520 --> 01:23:26.039
they sent them a threatening email and they basically responded
1488
01:23:26.159 --> 01:23:30.359
with First Amendment bitches. And it will be interesting to
1489
01:23:30.399 --> 01:23:32.880
see where this goes. So yeah, that would be my
1490
01:23:33.000 --> 01:23:38.039
second pick. And I think you can tell which side
1491
01:23:38.079 --> 01:23:41.760
them on in this argument, or put it this way,
1492
01:23:41.920 --> 01:23:44.479
The worst thing that has ever ever happened to the web,
1493
01:23:44.520 --> 01:23:46.399
I think is GDPR.
1494
01:23:46.960 --> 01:23:47.359
Yes, and.
1495
01:23:50.079 --> 01:23:51.600
Yeah, we don't need any more of that.
1496
01:23:52.439 --> 01:23:55.600
So yeah, those would be my two picks for today.
1497
01:23:55.720 --> 01:23:57.720
All right, Tanner, you got any picks for us?
1498
01:23:57.920 --> 01:24:01.800
Picks? Picks them of these pics? Do these picks needed?
1499
01:24:02.039 --> 01:24:06.640
Is random the room? The randomer the better, randomer the better.
1500
01:24:07.000 --> 01:24:09.880
Okay, why you think about it, We'll go to Ryan.
1501
01:24:09.960 --> 01:24:11.079
See if Ryan anything.
1502
01:24:11.960 --> 01:24:14.880
Ryan, I'm just gonna think here because I've been so busy.
1503
01:24:15.039 --> 01:24:17.279
If you guys don't know, I have a little baby
1504
01:24:17.439 --> 01:24:20.760
at home, so I have that to your pick. Yeah,
1505
01:24:20.800 --> 01:24:24.119
I mean, I mean, honestly, I don't get to watch
1506
01:24:24.199 --> 01:24:26.199
or check out nearly as much as I want to
1507
01:24:26.479 --> 01:24:28.920
that and like kids shows. I recently watched what it
1508
01:24:28.960 --> 01:24:30.600
was like K Pop Demon Hunters.
1509
01:24:31.319 --> 01:24:32.920
I've heard real good things about that one.
1510
01:24:32.960 --> 01:24:35.479
Yeah, you know, I mean if I mean, people are
1511
01:24:35.479 --> 01:24:38.000
gonna disagree with me, but it gave me like it's
1512
01:24:38.039 --> 01:24:42.279
got almost like Sailor Moon vibes, but like some big production,
1513
01:24:43.720 --> 01:24:45.159
you know, thang it.
1514
01:24:45.159 --> 01:24:46.640
It was fun, the kids liked it.
1515
01:24:47.600 --> 01:24:49.920
Since you mentioned the show, and to give Tennor a
1516
01:24:50.000 --> 01:24:52.119
little bit more time, I have to say that I
1517
01:24:52.319 --> 01:24:57.000
was really disappointed with the second season of San I mean,
1518
01:24:57.199 --> 01:25:00.920
they had an entire episode which was literally funeral. I
1519
01:25:00.960 --> 01:25:02.560
mean what the half.
1520
01:25:02.640 --> 01:25:05.159
I haven't watched that one, so I can't.
1521
01:25:05.640 --> 01:25:07.359
Oh, I know, I know what else I want to
1522
01:25:07.359 --> 01:25:09.319
say without giving away too much. I actually enjoyed the
1523
01:25:09.399 --> 01:25:11.960
ending of season three of Squid game station to have
1524
01:25:12.000 --> 01:25:15.359
split it, but oh really, but I like the second
1525
01:25:15.399 --> 01:25:18.479
third season together. It ended in a I like the
1526
01:25:18.479 --> 01:25:20.800
way it ended, So maybe I'm made me minority. But
1527
01:25:20.840 --> 01:25:23.560
I actually if if if you're willing to watch the
1528
01:25:23.600 --> 01:25:26.000
second season, that you should finish it with the third season.
1529
01:25:26.279 --> 01:25:28.479
Well, yeah, is really into that one, and he was
1530
01:25:28.520 --> 01:25:30.359
explaining the plot to me. I haven't watched the NAVA,
1531
01:25:30.399 --> 01:25:32.640
but he's explaining to me, and I mean, it sounded
1532
01:25:33.039 --> 01:25:35.079
the first season is just creeped me out. It was
1533
01:25:35.119 --> 01:25:36.880
more of a Hunger Games type vibe and it just
1534
01:25:37.000 --> 01:25:39.720
sort of creeped me out. But he was explaining what
1535
01:25:39.880 --> 01:25:41.720
was going on in the second third seasons to me,
1536
01:25:41.800 --> 01:25:44.279
and that's that's pretty intriguing the way they're doing it
1537
01:25:44.680 --> 01:25:45.000
right now.
1538
01:25:45.119 --> 01:25:46.880
Thank you word for it, as long as you don't
1539
01:25:46.880 --> 01:25:49.479
tell me that you enjoyed the eighth season of Game
1540
01:25:49.479 --> 01:25:50.039
of Thrones.
1541
01:25:52.000 --> 01:25:54.640
No, no, that was that was not my favorite. All right, Tanner,
1542
01:25:54.680 --> 01:25:55.439
we gave you some time.
1543
01:25:55.479 --> 01:25:58.119
What do you got. I mean, I like Ryan I,
1544
01:25:58.199 --> 01:26:02.760
so I don't consume a whole lot of of what's
1545
01:26:02.800 --> 01:26:06.920
out there. I'm I'm more of a builder, but there
1546
01:26:07.159 --> 01:26:09.520
there are a few things that I do I do enjoy.
1547
01:26:09.600 --> 01:26:14.359
So I'm overly hyped for the new season of Stranger
1548
01:26:14.399 --> 01:26:17.800
Things coming out, and so we've been rewatching all of
1549
01:26:17.840 --> 01:26:20.279
the seasons before it. So that means that I've seen
1550
01:26:20.279 --> 01:26:23.479
the fourth the first season four times, the second season
1551
01:26:23.520 --> 01:26:27.239
three one, and so forth, and we're watching the fourth
1552
01:26:27.279 --> 01:26:29.800
season four the second time now, and then we're going
1553
01:26:29.840 --> 01:26:31.840
to anxiously await number five. Yeah.
1554
01:26:32.079 --> 01:26:35.359
That's an interesting argument that I had with aj about
1555
01:26:36.920 --> 01:26:41.199
fantasy book series that tend to come, you know, not
1556
01:26:41.279 --> 01:26:44.600
yet finished, and then the next book comes three years
1557
01:26:44.640 --> 01:26:47.560
after the previous book, and you don't remember anything. And
1558
01:26:47.640 --> 01:26:50.520
I never have it in me to reread that those
1559
01:26:50.600 --> 01:26:53.640
previous books. So you're basically you do have it in
1560
01:26:53.680 --> 01:26:55.399
you to rewatch the entire series.
1561
01:26:55.439 --> 01:26:58.800
They were they were so good, and you know, Stranger
1562
01:26:58.880 --> 01:27:03.479
Things connoisseurs will tell you, well, this season was worse
1563
01:27:03.520 --> 01:27:07.399
and this season was terrible, and but like going back
1564
01:27:07.439 --> 01:27:10.439
and watching them, I mean, I'm it's been a long
1565
01:27:10.439 --> 01:27:12.600
time since the first one came out, so like, I
1566
01:27:12.600 --> 01:27:15.359
am very much more adult now than I was then
1567
01:27:15.720 --> 01:27:20.039
watching them, and just the the acting from these kids
1568
01:27:20.319 --> 01:27:25.399
is just incredible. It really is so good. And and
1569
01:27:25.439 --> 01:27:28.119
the writing for for how quick they were taking out
1570
01:27:28.159 --> 01:27:31.439
the first couple of seasons, like the writing in some places,
1571
01:27:31.479 --> 01:27:33.239
I was like, okay, like that could have been better,
1572
01:27:33.239 --> 01:27:37.399
But for the most part, we're just spoiled with great content,
1573
01:27:37.560 --> 01:27:43.039
like what a fun story, a great story. And yeah,
1574
01:27:43.159 --> 01:27:45.119
I was just telling my wife. Season four got a
1575
01:27:45.159 --> 01:27:48.159
little dicey because it started feeling really evil, and I
1576
01:27:48.199 --> 01:27:49.399
was like, well, I don't know if I want to
1577
01:27:49.439 --> 01:27:51.039
take part in this anymore. And then all of a
1578
01:27:51.039 --> 01:27:53.920
sudden it went super sci fi and I was like, okay,
1579
01:27:53.960 --> 01:27:59.039
this is awesome. So yeah, we've been watching Stranger Things
1580
01:27:59.079 --> 01:28:02.880
and that's about the only like one episode at night
1581
01:28:02.960 --> 01:28:06.880
and then I'm asleep, so that's about the amount of
1582
01:28:06.880 --> 01:28:08.119
time that I have to consume.
1583
01:28:08.399 --> 01:28:11.600
How old are your kids, if I might ask, I.
1584
01:28:11.600 --> 01:28:15.720
Have a a seven year old, a four year old,
1585
01:28:16.039 --> 01:28:20.520
and a almost two year old, So well, I'm not
1586
01:28:21.119 --> 01:28:25.960
they're not watching Stranger Things right now? For them? Is
1587
01:28:26.119 --> 01:28:28.760
I just really I just introduced them to spy kids
1588
01:28:30.119 --> 01:28:33.600
and they are like, this is the coolest series ever made,
1589
01:28:34.319 --> 01:28:37.239
So you know, they're they're living in a different world
1590
01:28:37.319 --> 01:28:41.359
right now. That's just as cool, but way more child friendly.
1591
01:28:42.079 --> 01:28:44.680
No, I was asking for the perspective of your free
1592
01:28:44.720 --> 01:28:48.119
time because, like Ryan said, then you have little children
1593
01:28:48.159 --> 01:28:48.520
at home.
1594
01:28:48.880 --> 01:28:51.880
Yeah, we both have little children, and I know that
1595
01:28:52.159 --> 01:28:56.039
I know from talking to Fran that they consume, happily
1596
01:28:56.359 --> 01:29:00.520
consume a lot of our time. So yeah, I it's
1597
01:29:00.560 --> 01:29:03.840
basically at night for maybe an hour that you know,
1598
01:29:03.880 --> 01:29:06.640
we get to indulge in something.
1599
01:29:06.760 --> 01:29:10.000
So all I can say though is from watching from
1600
01:29:10.039 --> 01:29:13.399
the other side as it were enjoyed while it lasts.
1601
01:29:13.520 --> 01:29:15.159
Yes, oh yeah for sure.
1602
01:29:15.279 --> 01:29:18.680
Yeah, mine are twenty five, about to get married twenty
1603
01:29:18.720 --> 01:29:23.439
two and Congratulateen, and so yeah, we have a lot
1604
01:29:23.479 --> 01:29:26.239
more a little more free time. But yeah, I missed
1605
01:29:26.279 --> 01:29:28.119
some of those. I'm looking forward to grandkids and be
1606
01:29:28.199 --> 01:29:30.079
able to have the kids into then say here you go,
1607
01:29:31.279 --> 01:29:31.560
you know.
1608
01:29:31.680 --> 01:29:35.000
Yeah, well my baby goes twenty three years old working
1609
01:29:35.039 --> 01:29:35.479
in tech.
1610
01:29:36.720 --> 01:29:37.199
Very cool.
1611
01:29:37.800 --> 01:29:40.159
Yeah all right, So with that, we're going to wrap
1612
01:29:40.199 --> 01:29:42.239
this up and hopefully we'll have these two backing in
1613
01:29:42.319 --> 01:29:45.840
to continue our discussion in the meantime. Thanks for watching
1614
01:29:45.880 --> 01:29:48.159
slash listening, and we'll talk at you next time.
1615
01:29:48.279 --> 01:29:50.880
Bye.
