WEBVTT

1
00:00:06.200 --> 00:00:12.000
Hello everybody, and welcome to another
episode of JavaScript Jobber. Today you have

2
00:00:12.320 --> 00:00:16.519
just me Dan shap here, your
hostest with the mostest, coming to you

3
00:00:16.559 --> 00:00:23.120
from Tel Aviv, and uh with
me, it's Hi Resnick coming from Israel

4
00:00:23.120 --> 00:00:30.480
Awareness Israel. Remind me please vision
Zon vision that Yeah, yeah, a

5
00:00:30.559 --> 00:00:36.560
town and uh. We are both
here today to talk about all sorts of

6
00:00:36.799 --> 00:00:43.920
JavaScript related goodness, specifically about the
Quick framework, about JavaScript streaming and lots

7
00:00:43.920 --> 00:00:47.840
of other great things. Before we
start, Shy, maybe you can introduce

8
00:00:47.840 --> 00:00:53.079
yourself. Yeah, sure, and
we could also play out all the other

9
00:00:53.200 --> 00:00:58.039
voices that people are used to know
hearing, like Chuck and Jane. Yeah,

10
00:00:58.600 --> 00:01:02.640
it's just the two of us here
to day. That's okay. They

11
00:01:02.640 --> 00:01:07.760
will have pomo. Hey, I'm
Shy Resnick. I'm part of the Quick

12
00:01:07.840 --> 00:01:12.000
team. Also the founder of highersio, where we make web development fun and

13
00:01:12.040 --> 00:01:21.680
efficient by courses and consulting and such. And yeah, I run the larger

14
00:01:21.799 --> 00:01:32.239
JavaScript meetup group in Israel, over
eleven thousand developers. Yeah. And also

15
00:01:32.640 --> 00:01:36.280
as a hobby, I do improv
and stand up and stuff like that.

16
00:01:36.359 --> 00:01:41.319
I like to do entertaining talks all
over the world about JavaScript and trying to

17
00:01:41.359 --> 00:01:45.560
make it less boring. Yeah,
that's me. JavaScript is not boring.

18
00:01:45.719 --> 00:01:51.239
JavaScript is the most exciting thing ever. Yeah, yeah, yeah, I

19
00:01:51.319 --> 00:01:57.120
totally agree, depending on which topics
I'm guessing. Yeah, it's so exciting

20
00:01:57.159 --> 00:02:02.239
that we're in the process of replacing
it with typescript. Well, it is

21
00:02:02.400 --> 00:02:07.079
kind of the same, right,
Like I wouldn't mind if typescript was.

22
00:02:07.439 --> 00:02:12.960
But yeah, that's a hot topic. I've heard several interesting points in this

23
00:02:13.039 --> 00:02:17.560
regard. One A J likes to
refer to to typescript as a super set

24
00:02:17.719 --> 00:02:23.639
of a subset of JavaScript, which
means that it's a totally distinct programming language.

25
00:02:23.520 --> 00:02:30.240
And the other interesting point I made, I think it was from what's

26
00:02:30.240 --> 00:02:32.520
his name, Mario Kalina, I
think is the guy is the main one

27
00:02:32.560 --> 00:02:43.879
of the maintainers of node Matteo.
He says that because every different configuration of

28
00:02:44.280 --> 00:02:50.360
every different thing you put in tis
configure basically creates like a different programming language.

29
00:02:50.400 --> 00:02:54.719
So JavaScript isn't so Typescript isn't really
a programming language. It's a multiverse

30
00:02:54.759 --> 00:03:01.280
of programming languages probably, but hey, it helps with the enterprise scale refactoring,

31
00:03:01.400 --> 00:03:07.240
so I'm happy with it, that's
for sure. Yeah, I'm wondering

32
00:03:07.280 --> 00:03:15.560
how many of your consulting gigs are
helping companies transition from jobscript code bases to

33
00:03:15.639 --> 00:03:21.360
typescript. Oh no, I think
more by this time most of of the

34
00:03:22.319 --> 00:03:25.759
you know, our industry are in
typescript. I think there was a time,

35
00:03:25.800 --> 00:03:29.800
you know, ten years ago or
something like that where people still debated

36
00:03:30.199 --> 00:03:35.199
whether it's typescript or flow, or
like whether we should stay with Vanilla.

37
00:03:35.599 --> 00:03:38.919
I think by this point everybody kind
of understand that, you know, if

38
00:03:38.960 --> 00:03:43.319
you want to do, if you
want to save a lot of time,

39
00:03:43.560 --> 00:03:49.120
and you know, have a cleaner
code base in terms of like understandability of

40
00:03:49.439 --> 00:03:55.000
you know, what this code actually
does. I think typescript is the default.

41
00:03:55.319 --> 00:04:00.680
So oh yeah, I totally agree. It's just that taking any existing

42
00:04:00.439 --> 00:04:05.800
large scale JavaScript code based and transitioning
it into Typescript can be a challenge.

43
00:04:05.800 --> 00:04:14.680
So I'm wondering how many organizations are
still stuck with either actual JavaScript code basis

44
00:04:14.840 --> 00:04:19.560
or code basis that they have theoretically
transitioned to typescript but in reality are mostly

45
00:04:19.639 --> 00:04:26.720
untyped. Yeah. I don't have
the statistics, but I'm guessing like you

46
00:04:26.920 --> 00:04:31.920
still have a you know, project
with only Jaquery or just vanilla JavaScript.

47
00:04:32.319 --> 00:04:38.839
Pretty sure they're there in the wild, but don't knock jaquerry. The new

48
00:04:38.920 --> 00:04:44.839
version has just come out. No, then, wasn't an yeah totally for

49
00:04:44.879 --> 00:04:49.600
it, But yeah, that's so
typescript. I think it's kind of the

50
00:04:49.680 --> 00:04:57.199
standard these days. And you know, what's not yet the standard? What's

51
00:04:57.279 --> 00:05:03.759
not yet the standard JavaScript streaming?
Glad you asked, And that's what we're

52
00:05:03.800 --> 00:05:09.160
here to talk about. Maybe we'll
make it a standard. Yep, yeah,

53
00:05:09.360 --> 00:05:15.800
I hope so yeah, so so
yeah, that's ah, where do

54
00:05:15.839 --> 00:05:20.240
you want to start from the beginning, like beginning it seems like a good

55
00:05:20.439 --> 00:05:24.839
Yeah, beginning seems like a good
place to start. Yeah, okay,

56
00:05:24.879 --> 00:05:30.759
cool. So I was born in
in nineteen eighty three. No, so

57
00:05:31.720 --> 00:05:35.360
what kind of wait a minute,
you are you? Just you made the

58
00:05:35.399 --> 00:05:41.439
Big four? All yep, yeah, I'm all still and you still have

59
00:05:41.560 --> 00:05:46.360
your hair. Yeah I look sixteen, I know, but I'm all older

60
00:05:46.839 --> 00:05:56.120
at least. So yeah, it's
kind of like the whole jobaskul, like

61
00:05:56.160 --> 00:06:03.639
streaming a metaphor kind of ties to
you, like my whole journey with with

62
00:06:03.839 --> 00:06:09.879
Quick, which was a weird journey, how I got introduced to it and

63
00:06:09.959 --> 00:06:15.160
also how I ended up joining the
team and helping like weird journeys, can

64
00:06:15.199 --> 00:06:19.000
you can you elaborate? Yeah?
Okay, So I think three years ago

65
00:06:19.079 --> 00:06:26.040
or something like that, I talked
with Michele Heavry, who created Quick and

66
00:06:26.040 --> 00:06:30.360
also Angular. We've been friends for
a couple of years. Ever since.

67
00:06:30.399 --> 00:06:36.360
I gave him a funny T shirt
at Angie Conf on stage a grand guy.

68
00:06:36.519 --> 00:06:42.319
I really like it. Yeah,
yeah, is awesome. I gave

69
00:06:42.360 --> 00:06:46.360
him a T shirt saying transclusion,
I don't think it means what you think

70
00:06:46.399 --> 00:06:50.439
it means, or something like that. You keep using that word about the

71
00:06:50.480 --> 00:06:57.920
weird choice of words in Angular JS. And ever since then we we became

72
00:06:58.000 --> 00:07:01.399
friends and and say staying in touch
and we talked just just before he left

73
00:07:01.480 --> 00:07:08.759
the left Google to join a new
startup called bill Loreo. He shared with

74
00:07:08.800 --> 00:07:15.240
me that he's working on this new
cool framework called Cute and I was like,

75
00:07:15.360 --> 00:07:20.040
cute, Yeah, but you spell
it qoot and I said cute.

76
00:07:20.560 --> 00:07:25.160
I said, no, cute And
I was like, Michico, we need

77
00:07:25.720 --> 00:07:30.680
a different name. I will need
to digress you. There was this movie

78
00:07:30.839 --> 00:07:35.759
like I don't know a few decades
ago about this band. I think Tom

79
00:07:35.839 --> 00:07:41.360
Hanks was the director or he wrote
the script and the name of the band

80
00:07:41.759 --> 00:07:46.240
was. They decided to call themselves
the Wonders. It was like a band

81
00:07:46.279 --> 00:07:49.879
in the fifties, but they wrote
it like one, like the word the

82
00:07:49.959 --> 00:07:57.759
number one, so everybody would call
them the own leaders. So eventually,

83
00:07:58.399 --> 00:08:01.800
so eventually the record label change their
name to be one the Wonders, like

84
00:08:03.079 --> 00:08:07.319
spell normally and normally. Yeah.
Yeah, So that that that was like,

85
00:08:07.079 --> 00:08:15.160
you know, the the weird naming
decision at the beginning. And it

86
00:08:15.279 --> 00:08:18.560
showed me a demo he said,
you want to shore sea Demon if you

87
00:08:18.600 --> 00:08:22.879
know, mischo is very excited about
showing the beats and pieces of hout the

88
00:08:22.920 --> 00:08:28.319
technology works and such. So it
just like threw all this information on me

89
00:08:28.360 --> 00:08:33.240
and hours at the time like focused
solely on testing and TDD and helping companies

90
00:08:33.240 --> 00:08:35.240
with that, and I was like
out of context of all like you know,

91
00:08:35.399 --> 00:08:41.080
the meta framework you know game back
then and all that stuff. So

92
00:08:41.120 --> 00:08:48.559
it started like like showing me that
if you create all these like files manually

93
00:08:48.960 --> 00:08:54.120
and encode all the information in the
HTML manually, and if you do all

94
00:08:54.159 --> 00:08:58.159
this manual stuff, when you load
the app, it will be instant.

95
00:08:58.639 --> 00:09:01.879
You have no you'll have no delay, and you could just do it.

96
00:09:03.000 --> 00:09:09.279
And I looked at it and I
could only understand like twenty percent of everything

97
00:09:09.480 --> 00:09:13.919
said it said, But I got
it that there's some innovation here where you

98
00:09:15.000 --> 00:09:20.120
and code stuff in the HTML.
Like that was something that I didn't really

99
00:09:20.159 --> 00:09:26.200
see before about like framework state that
the HTML remembers from the server. So

100
00:09:26.240 --> 00:09:31.759
I said, like that that's cool, Like it's very innovative, and he

101
00:09:31.799 --> 00:09:35.799
said like, okay, so you're
ready to you know, write some content

102
00:09:35.879 --> 00:09:39.840
about it or videos or you know, like join. He sent me like

103
00:09:39.279 --> 00:09:43.519
a link to get up right away, so you know, maybe I could

104
00:09:43.519 --> 00:09:50.279
contribute and such. And I had, like I had this intuition, you

105
00:09:50.360 --> 00:09:54.240
know how you have this intuition where
you cannot explain but you just feel if

106
00:09:54.279 --> 00:09:56.960
it's like the right thing or the
wrong thing, or like you know,

107
00:09:58.000 --> 00:10:01.200
how you feel about it. So
I was like, I was like,

108
00:10:01.480 --> 00:10:07.039
yeah, I'm not sure. Like
I was like, yeah, I'm super

109
00:10:07.080 --> 00:10:11.679
busy now I have like courses to
create and such, and it's it's a

110
00:10:11.679 --> 00:10:15.919
hard thing, you know, because
you know, it sounds it sounded innovative,

111
00:10:15.960 --> 00:10:22.759
it looked innovative, but I really
like something felt wrong, and after

112
00:10:22.879 --> 00:10:28.360
the fact, I thought with myself
like what what made me like say,

113
00:10:28.759 --> 00:10:35.240
not really? And I realized that
it was the whole manual thing like I

114
00:10:35.320 --> 00:10:39.399
needed to do. You know,
if you go through the history right and

115
00:10:39.960 --> 00:10:43.759
you see, I think you've been
the talk where I went over like,

116
00:10:43.840 --> 00:10:48.960
you know, the history like the
last twenty years of web development. So

117
00:10:50.000 --> 00:10:54.159
we saw, I showed her that, you know, we go through went

118
00:10:54.240 --> 00:11:00.879
through the cycle of you know,
user experience and you know, developer experience

119
00:11:00.960 --> 00:11:03.759
right like we should, by the
way, we should probably put a link

120
00:11:03.799 --> 00:11:07.600
to the talk in the show notes
afterwards. Yeah, now there's an updated

121
00:11:07.679 --> 00:11:16.440
version of it that I did in
JS world from last month supposed to be

122
00:11:18.080 --> 00:11:22.919
yeah, waiting for them to release
the videos, but but yeah, but

123
00:11:22.919 --> 00:11:28.840
but in short, it was basically, you know, if you think about

124
00:11:28.879 --> 00:11:33.000
the last twenty years, we've went
through you know, the the MPAs to

125
00:11:33.120 --> 00:11:39.279
the to d HTML and then you
know spas like single page apps and then

126
00:11:39.399 --> 00:11:43.759
hybrid apps with like you know SSR
and the new hydration and such, and

127
00:11:43.840 --> 00:11:50.240
every time it was like user experience
and developer experience basically fighting, you know

128
00:11:50.279 --> 00:11:54.480
with each other. You want more
features, but then you're you know,

129
00:11:54.600 --> 00:12:00.440
taking taking a loss on the user
experience side. And which basically means that

130
00:12:00.960 --> 00:12:05.480
how fast that that users can you
know, reach their goal. Basically,

131
00:12:07.480 --> 00:12:11.080
yeah, I know what you mean. It's kind of it's it's also this

132
00:12:11.200 --> 00:12:18.759
whole transition of going from websites to
web apps and what does it actually even

133
00:12:18.879 --> 00:12:24.679
mean to be an app on the
web, and of course going from desktops

134
00:12:24.679 --> 00:12:30.240
to mobile. There were a lot
of transitions going on more or less at

135
00:12:30.240 --> 00:12:37.639
the same time that all got in
the way of providing you know, holistically

136
00:12:37.639 --> 00:12:45.159
good experience to end users and simultaneously
making things, let's call it manageable for

137
00:12:45.200 --> 00:12:50.679
the developers exactly. So that that
was like, that was their conclusion that

138
00:12:50.759 --> 00:12:54.720
I got to, which is,
you know, we strive with all these

139
00:12:54.759 --> 00:12:58.879
transitions for apps. We wanted to
have a desktop like experience like for the

140
00:12:58.000 --> 00:13:01.440
users, right like something it opens
right away, you stay in there,

141
00:13:01.840 --> 00:13:05.360
it remembers what you typed, you
know, and all that stuff. You

142
00:13:05.399 --> 00:13:09.240
can go back and forth and such. But it wasn't enough like just you

143
00:13:09.240 --> 00:13:13.279
know, focus on that experience because
developers. You know, what I realized

144
00:13:13.879 --> 00:13:20.039
is that developers care about this stuff
like user experience as long as it doesn't

145
00:13:20.039 --> 00:13:26.080
interfere with their development experience, right
Like if you ask them to do these

146
00:13:26.120 --> 00:13:30.240
extra steps, they will only do
it if they have to write. It's

147
00:13:30.279 --> 00:13:33.600
just like some of the developers were
testing. They test after the fact because

148
00:13:33.639 --> 00:13:37.519
they have to or the you know, it's it's not really part of the

149
00:13:37.720 --> 00:13:43.440
process because it's extra steps. And
when you don't see the benefit of it

150
00:13:43.559 --> 00:13:46.039
or you don't feel the pain yourself, then you just like you know,

151
00:13:46.480 --> 00:13:50.159
want to focus on what you In
other words, what you're saying, is

152
00:13:50.159 --> 00:13:54.320
that real lazy? Of course?
Yeah, yeah, I think it's a

153
00:13:54.360 --> 00:13:58.720
good thing though. Yeah, for
sure. I like to say that software

154
00:14:00.000 --> 00:14:05.120
development is one field where procrastination is
often a good thing because maybe you'd end

155
00:14:05.200 --> 00:14:07.919
up not having to do it at
all, exactly if you wait long enough,

156
00:14:07.960 --> 00:14:18.320
maybe the browsers will implement signals for
you exactly. So so coming back

157
00:14:18.360 --> 00:14:22.080
to that point where I said Michico, I said to Misco like, well,

158
00:14:22.120 --> 00:14:26.440
I'm not sure and such. It
was because I had this intuition because

159
00:14:26.960 --> 00:14:30.600
there was like the developer experience was
lacking, right, Like I had to

160
00:14:30.639 --> 00:14:33.120
do all this manual stuff, and
I thought to myself, well, nobody

161
00:14:33.159 --> 00:14:37.960
will want to actually do that to
just shave off like a couple of milliseconds

162
00:14:37.960 --> 00:14:43.519
of the loading time. It's not
really a big problem. And I don't

163
00:14:43.519 --> 00:14:50.799
know it wasn't excited about it.
Now, Like a year went by and

164
00:14:52.720 --> 00:14:58.159
I offered my help along the way
in terms of like advice and trying like

165
00:14:58.279 --> 00:15:01.320
ideas and all that stuff, but
it didn't have really time to get involved.

166
00:15:01.840 --> 00:15:07.519
Here went by and because of COVID, we start doing remote talks in

167
00:15:09.279 --> 00:15:13.480
our meetup group. So at one
of those remote talks, I invited Michko

168
00:15:13.559 --> 00:15:18.399
to speak about We had a meet
up about like future frameworks. So we

169
00:15:18.399 --> 00:15:24.639
invited Mischko to to speak about now
quick not cute but still spelled wrong though

170
00:15:26.240 --> 00:15:31.639
yeah, still with a twist.
Yeah. So I invited to talk about

171
00:15:31.639 --> 00:15:35.679
that, and I was like in
a much busier time at my life,

172
00:15:35.720 --> 00:15:41.039
even like you know before when we
talked, like a year later, I

173
00:15:41.159 --> 00:15:45.919
was super busy, like managing a
business and uh, trying to to to

174
00:15:46.399 --> 00:15:52.320
juggle between like course recording and new
clients coming in and employees and everything together

175
00:15:52.720 --> 00:15:56.399
and you know, having a family
and wife and two kids and and so

176
00:15:56.840 --> 00:16:00.799
I was like late in the evening
getting a call from my wife like are

177
00:16:00.799 --> 00:16:03.720
you coming home? I need help? Uh, And I was like,

178
00:16:03.000 --> 00:16:08.440
damn it, I forgot that we
have this meetup today with Mischko and we're

179
00:16:08.440 --> 00:16:14.759
supposed to like come online and join
us in a in f an hour or

180
00:16:14.799 --> 00:16:17.240
something like that. And she was
like, okay, I will take care

181
00:16:17.240 --> 00:16:22.200
of the kids. Okay. Uh
yes, shout out to Naga, I

182
00:16:22.240 --> 00:16:27.399
love you, thank you. So
so we had this meetup and in that

183
00:16:27.600 --> 00:16:34.879
meetup, he showed quick the new
version and he went through all, you

184
00:16:34.879 --> 00:16:38.759
know, the explanations and stuff,
but he showed something completely different than what

185
00:16:38.840 --> 00:16:42.879
he showed me a year before,
because he said, well, you just

186
00:16:42.919 --> 00:16:48.320
write these JSX and that's it.
Everything done is done for you and you

187
00:16:48.360 --> 00:16:52.759
can just like you know, get
the instant loading app. And I was

188
00:16:52.799 --> 00:16:59.399
like, hmmm, where are all
the manual like writing of stuff and you

189
00:16:59.440 --> 00:17:03.960
know, inventing your own like file
names and stuff like that. And he

190
00:17:04.119 --> 00:17:08.599
shared that, you know, during
that time, he was joined by two

191
00:17:08.799 --> 00:17:15.759
brilliant developers, Adam Bradley and Manual
Media. Uh they are brilliant, by

192
00:17:15.759 --> 00:17:18.799
the way, I totally agree.
There are two of the most amazing developers

193
00:17:18.839 --> 00:17:23.079
that I know, Yes, exactly, and and they they both came from

194
00:17:23.200 --> 00:17:29.839
Ionic and created Stencil together. Uh. So they got excited about He got

195
00:17:29.839 --> 00:17:37.200
them excited about cute or quick,
and and and and there they got excited

196
00:17:37.920 --> 00:17:42.160
also about the potential to automate stuff
like not just getting the result, but

197
00:17:42.279 --> 00:17:48.240
also not just getting the user experience, but also getting the developer experience.

198
00:17:48.240 --> 00:17:51.720
So that's exactly what they did.
And one when he joined, he created

199
00:17:51.759 --> 00:17:57.960
a compiler called the Optimizer. Basically
it took all the manual steps and codify

200
00:17:59.079 --> 00:18:03.480
them and wrote a tool that does
that for us automatically, like all the

201
00:18:03.920 --> 00:18:10.559
you know, extraction of files and
renaming of things and really really hard problems

202
00:18:10.960 --> 00:18:15.519
to solve, and how to extract
closures into their own files, which is

203
00:18:15.559 --> 00:18:21.920
also a very difficult problem to solve. So together the dream team, you

204
00:18:21.960 --> 00:18:25.799
know, solve that problem and create
it the new version that he showed in

205
00:18:25.799 --> 00:18:30.119
the mediup. And I was like, now it's interesting. It's more interesting.

206
00:18:30.200 --> 00:18:33.400
I was still busy with all the
stuff, but I took a mental

207
00:18:33.440 --> 00:18:37.160
note and said to myself, well, I will check it out, like

208
00:18:37.759 --> 00:18:45.200
I will take my site project.
I agree that it's kind of necessary for

209
00:18:45.200 --> 00:18:48.359
for something like quick to succeed to
be developer friendly, because at the end

210
00:18:48.400 --> 00:18:53.279
of the day, if the goal
is to get good performance, but I

211
00:18:53.400 --> 00:18:57.880
have to work really hard for it
as a dev then I might as well

212
00:18:59.079 --> 00:19:03.160
work really hard on it from react
or something. You know. It's like

213
00:19:03.799 --> 00:19:08.799
the benefit of something like quick from
my perspective, and I think Mishko has

214
00:19:08.839 --> 00:19:14.759
also presented it this way is essentially
falling into the pit of success. Is

215
00:19:15.279 --> 00:19:22.079
I want to have the same challenges
that I have working development, you know,

216
00:19:22.160 --> 00:19:26.720
doing development in other frameworks, maybe
even less if possible, but the

217
00:19:26.759 --> 00:19:33.720
same at the most, but automatically
end up with much faster web applications or

218
00:19:33.759 --> 00:19:38.880
websites. Exactly. That's the low
like the barrier of entry at least should

219
00:19:38.880 --> 00:19:44.920
be exactly at least what you're used
to, if not way better, you

220
00:19:44.960 --> 00:19:48.079
know, way simpler to develop.
Even so, and one of the advantages

221
00:19:48.079 --> 00:19:56.200
that that the team had back then
in their disposal is that they were starting

222
00:19:56.200 --> 00:20:03.960
from scratch basically, so they just
could like take inspiration from different solutions and

223
00:20:03.319 --> 00:20:10.440
starts start from that point, like
taking reactivity, although it was really essential

224
00:20:10.480 --> 00:20:14.039
part to you know, be able
to do all this stuff, but also

225
00:20:14.240 --> 00:20:19.119
like looking at all this like tiny
developer experience happiness that you got from different

226
00:20:19.160 --> 00:20:26.079
frameworks and bake it in into this
framework to make sure that you start your

227
00:20:26.160 --> 00:20:30.880
starting point is amazing. And so
I took that, you know. A

228
00:20:30.920 --> 00:20:33.079
couple of days later, I took
a side project, you know, a

229
00:20:33.079 --> 00:20:37.400
website that I had and you know, with like a little bit of interactivity

230
00:20:37.440 --> 00:20:41.680
and refector it just just as a
POC, just to test the water,

231
00:20:42.000 --> 00:20:48.039
let's say. And and then I
deployed it and you know, test it

232
00:20:48.079 --> 00:20:52.279
on the paste peed stuff like to
see the result. And I got like

233
00:20:52.480 --> 00:20:56.119
nineteen nine on ideas or something like
that, and it was it had javas

234
00:20:56.160 --> 00:21:00.079
created, had like stuff in it. And I was like what, Like

235
00:21:00.519 --> 00:21:08.559
I couldn't believe that I just wrote
JavaScript and I got this score without manually

236
00:21:08.599 --> 00:21:14.279
optimizing anything I used to, like
you know, like rap stuff with like

237
00:21:14.319 --> 00:21:18.440
you know with rappers to yeah,
cashing and all the against that we that

238
00:21:18.519 --> 00:21:25.440
we do exactly. So I had
this emotional you know wave coming through,

239
00:21:25.720 --> 00:21:30.720
like you know, again this intuition
again struck me, but this time on

240
00:21:30.799 --> 00:21:34.839
the positive side and on the negative
side of like wow, if I have

241
00:21:36.000 --> 00:21:41.200
this feeling, it's like I want
this to be my future as a web

242
00:21:41.200 --> 00:21:47.720
developer, Like this is what I
want everybody to have to experience so this

243
00:21:47.839 --> 00:21:52.880
must be the future in terms of
technology. And when I looked more into

244
00:21:52.960 --> 00:21:56.160
it and spoke with Mischko and all
that stuff, he said that, you

245
00:21:56.160 --> 00:22:02.160
know, in order to bring it
to all of the rest of the firmworks

246
00:22:02.240 --> 00:22:07.079
that we need to make a lot
of breaking change, breaking changes in the

247
00:22:07.119 --> 00:22:11.759
ecosystem also like the API and all
that stuff. So it's basically it's very

248
00:22:11.920 --> 00:22:17.440
very very hard to do and will
be like you know, you know,

249
00:22:17.880 --> 00:22:22.640
like like in the past, nobody
likes the big migrations and stuff like that.

250
00:22:22.920 --> 00:22:26.480
I spoke about this with Wishko as
well on occasion, and he basically

251
00:22:26.559 --> 00:22:32.279
said, I think that initially when
he came up with this idea of streaming

252
00:22:33.200 --> 00:22:36.920
or resumability, I don't think he
was using the terms yet at the time,

253
00:22:37.079 --> 00:22:40.559
but as an alternative to hydration.
The problem that he was really looking

254
00:22:40.640 --> 00:22:45.440
to solve was the performance cost of
hydration, which we might you know,

255
00:22:45.599 --> 00:22:48.599
touch on it a little bit.
I've spoken about it in the past,

256
00:22:48.640 --> 00:22:52.880
but it might be worth part to
speak about it again. But he thought

257
00:22:52.880 --> 00:22:56.920
about initially doing it, I think
in the context of angular and he very

258
00:22:57.000 --> 00:23:06.440
quickly came to the realization that it
was just not doable without changing not only

259
00:23:06.480 --> 00:23:17.079
a lot of Angular internals, but
actually changing the API or or the the

260
00:23:17.119 --> 00:23:19.480
way that you actually use Angular.
That it couldn't stay Angular, that it

261
00:23:19.519 --> 00:23:26.920
would be like that transition from Angular
we want to do all over again.

262
00:23:26.039 --> 00:23:32.319
So you might as well start with
something fresh. And as you said,

263
00:23:32.400 --> 00:23:37.759
you know, picking JSX, it
basically looked at what was the kind of

264
00:23:37.039 --> 00:23:41.799
effectively industry standard at the time still
ongoing. Yeah, the most popular,

265
00:23:42.240 --> 00:23:51.799
which is the React and basically embracing
Embracing that as like you know where to

266
00:23:51.880 --> 00:23:56.000
start in terms of, you know, what the developer experience kind of feels

267
00:23:56.039 --> 00:23:59.680
like, even though it's it's not
exactly the same. And we can touch

268
00:23:59.720 --> 00:24:07.079
about other differences between React and quick
in terms of you know, the the

269
00:24:07.119 --> 00:24:11.680
primitives and the developer experience. Yeah. Yeah, So so basically, well

270
00:24:11.839 --> 00:24:18.079
this is a good point because that's
that's basically how I came into Like once

271
00:24:18.119 --> 00:24:22.559
I had this epiphany, I went
to like I schedule a call with with

272
00:24:22.680 --> 00:24:30.319
mich Coin and told him, hey, like I want to help, Like

273
00:24:30.640 --> 00:24:34.759
I remember when you asked me like
a year ago, and I didn't have

274
00:24:34.880 --> 00:24:38.759
time right, Like, I was
busier, but I know I had a

275
00:24:38.799 --> 00:24:45.920
wife that was you know about the
divorce before taken yet another project? Yeah,

276
00:24:47.319 --> 00:24:51.519
jokingly, yeah, but but yeah, but I was still like having

277
00:24:51.559 --> 00:24:55.599
this you know, invisible force,
you know, pulling me towards like,

278
00:24:56.160 --> 00:24:57.920
hey, I really want to get
involved. I want to be part of

279
00:24:57.960 --> 00:25:03.240
it. And I, as I
said in the beginning, I come with

280
00:25:03.279 --> 00:25:07.559
a lot of experience in like creating
communities and make and and being part of,

281
00:25:07.799 --> 00:25:12.200
you know, multiple communities along the
years since the nineties, and seeing

282
00:25:12.240 --> 00:25:18.319
what makes a good developer community and
what makes uh, you know, a

283
00:25:18.359 --> 00:25:26.000
bad community bad let's call it less
less successful? No I I specifically,

284
00:25:26.039 --> 00:25:30.279
I'm not talking about existing developer communities. I'm talking about communities in the past

285
00:25:30.319 --> 00:25:34.400
that I was part of which were
very toxic, toxic and they are not

286
00:25:34.519 --> 00:25:40.240
existing today because of that. So
that's why I call it bad. Uh

287
00:25:40.359 --> 00:25:42.599
So I and and and in between
you have always like you know, nothing

288
00:25:42.680 --> 00:25:45.480
is perfect, and you have in
between. But I learned lessons from it,

289
00:25:45.559 --> 00:25:49.279
and I really really wanted, you
know, for quick, to have

290
00:25:49.799 --> 00:25:56.839
a very friendly community and very helpful
and very beginner friendly, and and and

291
00:25:56.960 --> 00:26:02.480
and and in places that people feel
comfortable asking questions in and helping each other

292
00:26:02.599 --> 00:26:07.480
and grow and I knew that it
also will help growing the framework in terms

293
00:26:07.480 --> 00:26:12.319
of the ecosystem, because people will
not feel much better stuff. Undoubtedly,

294
00:26:12.519 --> 00:26:18.559
promoting a new framework is an uphill
battle. First of all, we're kind

295
00:26:18.559 --> 00:26:26.480
of spoiled for choice. I think
they're like, what eight major frameworks,

296
00:26:26.480 --> 00:26:30.519
maybe even more, and you know, I'm calling them major frameworks. But

297
00:26:30.559 --> 00:26:36.119
the reality is that React, for
now at least, remains the undoubted king

298
00:26:36.160 --> 00:26:40.039
of the hill. I think React
represents, you know, just React on

299
00:26:40.119 --> 00:26:45.720
its own has as many websites I
think in the Google Chrome user experience reports

300
00:26:45.759 --> 00:26:52.680
all the other frameworks put together.
So undoubtedly, pushing or promoting a new

301
00:26:52.759 --> 00:26:59.000
framework is, like I said,
is an uphill battle. And yeah,

302
00:26:59.079 --> 00:27:02.279
did you, by the way,
did you actually joined the royal or did

303
00:27:02.319 --> 00:27:07.359
you stay? So you're kind of
like a contractor a helper. No,

304
00:27:07.480 --> 00:27:11.799
I wasn't so so, as I
said, I had a business and employees

305
00:27:11.839 --> 00:27:15.039
and you know, obligations and all
that stuff. And I looked at it.

306
00:27:15.160 --> 00:27:18.880
You know, from the beginning,
they talked about the project as a

307
00:27:18.920 --> 00:27:25.519
community project, like they needed it
for you know, their products and and

308
00:27:25.519 --> 00:27:30.319
and that's why they invested in it. But they always talked about it as

309
00:27:30.400 --> 00:27:34.920
you know, being a community driven
project, and uh so I said,

310
00:27:34.960 --> 00:27:38.279
like, hey, I would join
as a community I don't know devl or

311
00:27:38.440 --> 00:27:45.039
you know, contributor to the community
because because the team was small at the

312
00:27:45.039 --> 00:27:48.599
time, they didn't have anyone you
know, focus on that because they were

313
00:27:48.680 --> 00:27:53.920
like working very hard on getting to
you know, version one. So I

314
00:27:55.039 --> 00:28:00.680
started helping with you know, writing
the community values and making sure that everybody

315
00:28:00.839 --> 00:28:07.119
feel welcomed, and you know,
started creating these groups and highlight certain people

316
00:28:07.119 --> 00:28:11.880
who are you know, extraordinary in
their contributions by creating the quick heroes and

317
00:28:12.160 --> 00:28:18.359
community leaders and meetups all around the
world. And I was focusing on mainly

318
00:28:18.400 --> 00:28:25.640
on debt and also started I knew
that in orders, like like you said,

319
00:28:25.640 --> 00:28:30.839
it's an uphill battle, and I
came at it from a different perspective

320
00:28:30.880 --> 00:28:33.960
in terms of like, let's say, the other solutions. I view all

321
00:28:34.000 --> 00:28:41.759
of the other solutions and it wasn't
a pun as one big Javaskist family basically

322
00:28:41.759 --> 00:28:47.799
because I come from many the Angular
community, which is also very friendly and

323
00:28:47.920 --> 00:28:52.200
very supportive, and I have lots
and lots of friends there, and I

324
00:28:52.240 --> 00:28:57.039
see other communities as well which are
very very friendly and very helpful and everybody

325
00:28:57.079 --> 00:29:00.640
basically is working towards the same goal, which is meant to make sure to

326
00:29:00.720 --> 00:29:07.039
make our lives better. So since
the beginning, one of our values that

327
00:29:08.759 --> 00:29:15.039
we're said, we said, what
was making sure that people in our community

328
00:29:15.279 --> 00:29:21.720
don't you know, talk badly about
other frameworks or solutions. Uh. From

329
00:29:21.759 --> 00:29:30.720
this this mindset of one big joba
skied family and everybody hates you. I

330
00:29:30.759 --> 00:29:36.599
actually, I actually was like in
just in just World in Amsterdam last months

331
00:29:36.920 --> 00:29:41.839
when I gave my talk. It
was mainly I think view developers and lots

332
00:29:41.880 --> 00:29:47.519
of the view ecosystem projects like nuts
and WAT and uh, everybody was so

333
00:29:47.519 --> 00:29:52.319
so friendly, gave me the same
exact vibes and feelings from the Angular community,

334
00:29:52.359 --> 00:29:56.039
which mostly you know, have been
to the Angular events. So that

335
00:29:56.240 --> 00:30:02.559
was another confirmation that we're all just
one big JavaScript family. And you know,

336
00:30:02.599 --> 00:30:06.480
people are arguing over developer experience in
terms of syntax and stuff like that,

337
00:30:06.519 --> 00:30:10.720
which is fine. Everybody has their
own taste, but together we can,

338
00:30:10.799 --> 00:30:14.599
like you know, march forward as
a group and try to make the

339
00:30:14.680 --> 00:30:21.319
web better. So I help,
I offer my help with that and start

340
00:30:21.319 --> 00:30:29.960
getting more and more involved. And
one of the things that offer to help

341
00:30:30.000 --> 00:30:33.400
with because I have a lot of
experience in creating courses and education and such,

342
00:30:34.039 --> 00:30:40.720
I noticed that the way that we
are explaining quick is lacking or it's

343
00:30:40.720 --> 00:30:45.359
too complicated, and we're losing I
felt that we're losing a lot of people

344
00:30:45.440 --> 00:30:51.920
along the way who are not yet
experts at you know, JavaScript or the

345
00:30:51.920 --> 00:30:55.440
firm or the ecosystem and all that
stuff in order to understand like why is

346
00:30:55.480 --> 00:31:00.440
it cool? So me and Michico
recorded a free course, a quick introduction,

347
00:31:02.920 --> 00:31:07.920
and we recorded it in one day, but then it took me like

348
00:31:08.119 --> 00:31:14.000
five months to re record parts after
Like the more I learned, the more

349
00:31:14.480 --> 00:31:19.680
I saw how we could simplify stuff. And that's where basically the JavaScript streaming

350
00:31:19.720 --> 00:31:26.440
metaphor came from. It's the metaphor
of streaming came from Mishko at one of

351
00:31:26.440 --> 00:31:33.880
the talks that we gave together in
Poland. But I was I insisted into

352
00:31:33.039 --> 00:31:40.359
trying to name it JavaScript streaming so
we could explain the metaphor and then to

353
00:31:40.440 --> 00:31:44.400
try and explain the metaphor to the
viewers. Okay, so you know,

354
00:31:44.960 --> 00:31:52.119
just like what is it? So
remember back in the day, we wanted

355
00:31:52.160 --> 00:31:56.920
to, you know, see a
movie. We had to download the entire

356
00:31:56.079 --> 00:32:00.960
movie gigabytes a file. Yeah,
I'm old enough to have been there.

357
00:32:01.720 --> 00:32:07.359
Yeah, and before that with vhs
and all the stuff. But anyway,

358
00:32:07.759 --> 00:32:13.079
I wanted to legally, of course, download the entire video and uh yeah,

359
00:32:13.359 --> 00:32:17.240
legally, and just to see the
end of the right the movie ors

360
00:32:17.359 --> 00:32:22.440
or to continue where we left off. But today we're not doing that anymore

361
00:32:22.480 --> 00:32:24.759
most of the time, right,
we have something else. Right, we

362
00:32:24.839 --> 00:32:30.839
have streaming. Yeah, so we
have Netflix and YouTube, and it's really

363
00:32:30.880 --> 00:32:32.960
easy to jump to the end or
to the last point where we stopped and

364
00:32:34.640 --> 00:32:38.759
just to continue watching that. And
that that metaphor, in a very simplistic

365
00:32:38.799 --> 00:32:47.599
way, is the metaphor behind the
innovation behind quick and so in order to

366
00:32:49.000 --> 00:32:52.880
like just compare it, because you
asked about the hydration just in one sentence.

367
00:32:53.000 --> 00:33:02.839
Hydration is basically the act of rerunning
the JavaScript framework on the client side

368
00:33:04.119 --> 00:33:09.799
after like to make sure that the
HTML that gets produced by the server,

369
00:33:10.440 --> 00:33:16.599
which is done by the server side
rendering in technologies like you know next JS

370
00:33:16.720 --> 00:33:23.480
or next or any hybrid technology that
runs like renders on the server. It

371
00:33:23.559 --> 00:33:30.279
produces an HTML which has no logic
in it, and then the framework needs

372
00:33:30.319 --> 00:33:34.279
to rerun again on the client and
in order to make this page interactive.

373
00:33:34.640 --> 00:33:38.200
That's basically, yeah, that's the
funny thing is and a lot of people

374
00:33:38.240 --> 00:33:45.680
I see still don't understand that point
that when you use service. So I'll

375
00:33:45.680 --> 00:33:47.359
pull back just a little bit,
if you excuse me, just to give

376
00:33:47.400 --> 00:33:53.240
a little bit more context. When
people moved to frameworks like React, the

377
00:33:53.359 --> 00:33:59.039
initial the initial approach, or Angular, the initial approach to these frameworks was

378
00:33:59.079 --> 00:34:01.400
to actually do all rendering on the
client side. So in the very old

379
00:34:01.480 --> 00:34:07.039
days, we would render everything on
the service side using something like PHP and

380
00:34:07.160 --> 00:34:12.920
send it down and then augment it
with jQuery or something like that. But

381
00:34:13.559 --> 00:34:19.119
if we wanted something that was really
a more sophisticated application like behavior and we

382
00:34:19.199 --> 00:34:23.480
needed much more sophisticated interactions, we
needed something like an Angular or React.

383
00:34:23.960 --> 00:34:28.639
But what we ended up doing is
doing all the rendering on the client side,

384
00:34:28.760 --> 00:34:32.440
and then we would initially just deliver
a blank page, then download all

385
00:34:32.440 --> 00:34:38.000
the JavaScript, then download all the
data, then run the JavaScript produced the

386
00:34:38.119 --> 00:34:43.199
UI, and only then would we
start downloading things like fonts and images and

387
00:34:43.199 --> 00:34:46.679
stuff like that. So the downside
with this approach was that we had the

388
00:34:46.840 --> 00:34:52.320
blank page effectively for a very long
time at the beginning of the process,

389
00:34:52.719 --> 00:34:57.079
and this was especially bad on mobile, where things are obviously slower, so

390
00:34:57.159 --> 00:35:01.760
people would literally look at the blank
white page for multiple seconds, even longer

391
00:35:01.880 --> 00:35:07.239
in some cases I've seen longer.
And then we got as a SR like

392
00:35:07.320 --> 00:35:12.199
you mentioned, which basically said,
okay, let's take this JavaScript and react

393
00:35:12.360 --> 00:35:15.599
and run it on the server produced
HTML, and then instead of sending down

394
00:35:15.599 --> 00:35:20.480
a blank page, we'll send the
initial view from the get go. But

395
00:35:20.719 --> 00:35:24.400
like you said, you got just
essentially an HTML. It's like a picture

396
00:35:24.760 --> 00:35:30.519
of the website rather than the actual
functioning website. And the crazy thing is

397
00:35:30.599 --> 00:35:36.440
that hydration process that in order to
make the page actually interactive, we had

398
00:35:36.440 --> 00:35:42.000
to effectively regenerate that initial HTML on
the client side, so we still had

399
00:35:42.039 --> 00:35:46.960
to download all the JavaScript, all
the data rerun it. The only benefit

400
00:35:47.039 --> 00:35:52.119
really was that the user at least
had the page to look at while all

401
00:35:52.159 --> 00:35:59.039
this stuff was going on and perceived
performance. Yeah exactly that if it happened

402
00:35:59.079 --> 00:36:02.079
quickly enough, then by the time
that user actually tried to interact with the

403
00:36:02.119 --> 00:36:07.239
page, hopefully you know that that
hydration process will be done and the page

404
00:36:07.280 --> 00:36:15.039
would actually be functional so the user
wouldn't actually notice that that delay. Yeah,

405
00:36:15.360 --> 00:36:17.159
and now I was challenging, like, in the course that you created,

406
00:36:17.320 --> 00:36:21.039
by the way, you could find
it on quick school dot com.

407
00:36:21.559 --> 00:36:24.360
It's free. You can just watch
it on that course. I'm challenging.

408
00:36:24.400 --> 00:36:29.840
I actually challenged Misko about this point, and because he was saying the same

409
00:36:29.880 --> 00:36:34.320
thing. He was saying like,
well, you know, people can wait

410
00:36:34.360 --> 00:36:37.880
for like thirty seconds to interact with
the page. And I was like,

411
00:36:37.840 --> 00:36:43.639
get out, Like nobody's waiting for
thirty seconds. And I actually experienced it

412
00:36:43.840 --> 00:36:49.039
later on myself by waiting being with
a low reception or something like that or

413
00:36:49.079 --> 00:36:55.159
connectivity and waiting for like some very
very simple page with some interactivity to load,

414
00:36:55.480 --> 00:37:00.599
and it was taking forever and forever
to load. And I was like,

415
00:37:00.800 --> 00:37:06.320
nope, not but even if it's
not forever, even if it's just

416
00:37:06.400 --> 00:37:10.639
a couple of seconds. So you
know, before I'm currently working at Next

417
00:37:12.119 --> 00:37:15.000
Insurance had nothing to do with next
JS, and prior to that, I

418
00:37:15.079 --> 00:37:19.760
worked at WIS. And at WIS, when when you're looking at the website

419
00:37:19.760 --> 00:37:23.119
on a mobile device, you usually
have a Hamburger menu. It's really common

420
00:37:23.159 --> 00:37:28.679
in a lot of websites, but
for the hamburger menu to work, it

421
00:37:28.880 --> 00:37:32.280
used to require the hydration to finish, so you would get the initial view

422
00:37:32.320 --> 00:37:37.840
of the page with the hamburger menu, but before the hydration actually finished,

423
00:37:38.280 --> 00:37:44.039
that hamburger menu wouldn't actually do anything. So you it's it's worse than a

424
00:37:44.079 --> 00:37:49.639
slow website is from my perspective,
it's a broken website because the users tap

425
00:37:49.719 --> 00:37:55.679
on that hamburger and literally nothing happens. And you know, that's like the

426
00:37:55.719 --> 00:37:59.840
worst user experience that there is.
Or think about a website. I go

427
00:38:00.280 --> 00:38:04.239
like a mark, like you know, a product page with a purchase button.

428
00:38:04.760 --> 00:38:08.880
Then you click that purchase button and
nothing happens. It's like the worst

429
00:38:08.920 --> 00:38:14.000
possible experience if I, you know, click a purchase button like once,

430
00:38:14.840 --> 00:38:19.880
or I'll be afraid to click it
twice because I'd be thinking, I don't

431
00:38:19.880 --> 00:38:23.079
want to purchase this product twice.
Yeah, a tow card like twice,

432
00:38:23.119 --> 00:38:30.480
and yeah and yeah and and I
basically just bounce so so and and and

433
00:38:30.519 --> 00:38:35.679
the and the point and the point
here. Like another realization that I had

434
00:38:35.760 --> 00:38:43.400
is that you don't see it when
you're developing locally or you're just testing out

435
00:38:43.440 --> 00:38:46.920
like a small demo. It only
bites you when you reach a certain point

436
00:38:47.079 --> 00:38:52.519
of an app size, And then
it becomes an issue because then all of

437
00:38:52.559 --> 00:38:58.440
the dependencies that you added to increase
your or to improve your developer experience,

438
00:38:58.599 --> 00:39:02.480
like this NPM package does this,
and this MPM packages does that, and

439
00:39:02.519 --> 00:39:07.039
you combine all of them, and
all of a sudden, this is part

440
00:39:07.079 --> 00:39:13.159
of your global share dependency that needs
to get downloaded as the first dependency for

441
00:39:13.239 --> 00:39:19.199
the hydration to finish up on every
page. Then it becomes a nightmare to

442
00:39:19.239 --> 00:39:23.719
try and then analyze the bundle and
see what are the biggest NPM packages that

443
00:39:23.760 --> 00:39:29.360
you can maybe replace. I don't
moment jes with date functions to like to

444
00:39:29.400 --> 00:39:31.800
make it more functions and all that
stuff. Right, what we said about

445
00:39:31.840 --> 00:39:37.079
falling into the pit of success,
it's this. This is exactly the opposite

446
00:39:37.119 --> 00:39:44.239
of that. It's literally falling into
a pit of vipers. Unless you actually

447
00:39:44.280 --> 00:39:49.760
invest potentially significant effort. By default, you'll end up with a bundle that

448
00:39:49.840 --> 00:39:54.320
includes everything. And that bundle,
by definition, can be you know,

449
00:39:54.559 --> 00:40:00.480
pretty big. You know, I've
seen multi megabytes of bundle, you know,

450
00:40:00.599 --> 00:40:06.239
if that is it compressed and whatnot? Still multiple megabytes yep, and

451
00:40:06.440 --> 00:40:10.639
ties it back by the way to
the metaphor of like video downloading. This

452
00:40:10.679 --> 00:40:17.280
is you as a user downloading the
entire video just to hit play and you

453
00:40:17.360 --> 00:40:22.440
know, waiting all this time just
to have the video playing or do something

454
00:40:22.519 --> 00:40:29.360
right. Yeah, and comparing that
with streaming, which is basically how quick

455
00:40:29.440 --> 00:40:31.760
works. This was like when I, when I, when I try to

456
00:40:32.159 --> 00:40:37.320
you know, looked at my definition
of like the generation of you know,

457
00:40:37.719 --> 00:40:40.760
technology innovation in technology. I was
like, you know, generation one was

458
00:40:40.800 --> 00:40:45.840
the NPA that you talked about with
the pitch pin or rendering. Generation one

459
00:40:45.920 --> 00:40:49.440
point five was you know, adding
a bit of JavaScript on top of it,

460
00:40:49.519 --> 00:40:52.400
like the dynamic htmail or something like
that that we call it. Generation

461
00:40:52.480 --> 00:40:57.599
two was single page apps, and
generation two and a half because it was

462
00:40:57.679 --> 00:41:00.039
again a laying a layer on top
of you know, the single page app

463
00:41:00.639 --> 00:41:04.800
was the hybrid. At least,
those are my definitions. It's not like

464
00:41:04.840 --> 00:41:09.039
scientific Now I try to think about
like, Okay, what's coming next,

465
00:41:09.400 --> 00:41:15.159
and what's coming next should should be
a completely paradigm shift, you know,

466
00:41:15.320 --> 00:41:20.800
compared to what it's It cannot be
just an improvement over what we already have.

467
00:41:21.039 --> 00:41:24.400
It needs to be something completely different, and it took me a while,

468
00:41:24.440 --> 00:41:30.960
but when I realized how quick works
or how JavaScript streaming works, I

469
00:41:30.039 --> 00:41:36.679
realized, hmm, we have not
we have in this a completely different paradigm

470
00:41:36.760 --> 00:41:42.719
shift. And then it hit me
why what Mishko was talking about about the

471
00:41:42.719 --> 00:41:49.360
philosophy of automatic automatic optimization basically that
you get up all the automization, but

472
00:41:49.440 --> 00:41:52.599
automatically done for you. So if
you if you want, we can dive

473
00:41:52.639 --> 00:41:57.280
into how jazz stream So we said, just to kind of put the point

474
00:41:57.280 --> 00:42:04.280
of where we are, so we
said that we regular SSR. The problem

475
00:42:04.480 --> 00:42:09.800
is that you get the initial rendered
view in the HTMIL really quickly, but

476
00:42:09.880 --> 00:42:14.639
then you have to, like you
said, like downloading the entire movie.

477
00:42:14.679 --> 00:42:16.320
It's like getting the first frame of
the movie. You see the first frame

478
00:42:16.320 --> 00:42:20.480
of the movie, but to see
the rest of the movie, even the

479
00:42:20.480 --> 00:42:23.840
second frame, you need to download
the entire movie and wait for the entire

480
00:42:23.880 --> 00:42:30.880
movie to finish downloading. And that's
what you get with most frameworks that use

481
00:42:31.320 --> 00:42:37.199
hydration. Now. I've actually given
a talk at at react next conference,

482
00:42:37.239 --> 00:42:40.800
for example, talking about various different
strategies that some frameworks have come up with

483
00:42:42.079 --> 00:42:47.000
in order to address this cost of
hydration like you might get something like progressive

484
00:42:47.079 --> 00:42:54.320
enhancement, which means that some functionality
can work before hydration actually happens. Or

485
00:42:54.400 --> 00:43:01.559
you've got technologies like React server components
where you can specify that, you know,

486
00:43:01.679 --> 00:43:07.400
some components being essentially static don't need
to hydrate, but anything that is

487
00:43:07.480 --> 00:43:13.960
dynamics still does need to hydrate and
stuff like that. And what you're saying

488
00:43:14.159 --> 00:43:22.360
is that with this JavaScript streaming approach, you're getting rid of hydration completely altogether,

489
00:43:22.519 --> 00:43:27.639
no hydration anymore, but you're still
getting all the benefits that you can

490
00:43:27.679 --> 00:43:34.639
build interact and you can build web
applications that are as interactive as you know,

491
00:43:35.239 --> 00:43:40.760
those classic single page applications written in
React or view or whatever. So

492
00:43:40.840 --> 00:43:45.360
can you elaborate on how this magic
kind of happens? Yeah, yeah,

493
00:43:45.119 --> 00:43:52.079
yeah, definitely. So just like
in video streaming, Okay, when you

494
00:43:52.119 --> 00:43:57.960
have like a big file of video, you want to chunk it into packets,

495
00:43:58.159 --> 00:44:00.840
right, this is basic when you
upload the video to YouTube. This

496
00:44:00.960 --> 00:44:07.360
is what happens behind the scenes and
through the technology of the server and the

497
00:44:07.400 --> 00:44:14.639
client, it gets streamed, it
gets chunked into encoded into a format,

498
00:44:14.679 --> 00:44:21.000
and then chunked into packets. And
then these packets are being streamed at the

499
00:44:21.000 --> 00:44:24.519
client the like based on the point
that of the movie that they wanted to

500
00:44:24.559 --> 00:44:29.480
watch, and it gets buffered right
when you post the movie, it actually

501
00:44:29.559 --> 00:44:32.039
buffers the next couple of packets or
the next, i don't know, twenty

502
00:44:32.079 --> 00:44:36.800
to thirty packets in orders for you
to have like a smooth experience, so

503
00:44:36.840 --> 00:44:39.920
you won't have like the you know, loading spinner every time you want to

504
00:44:39.960 --> 00:44:45.880
watch it if you have a slow
connection. So that's the same way that

505
00:44:45.559 --> 00:44:52.039
Quick and with the quick optimizer,
the compiler that manuro works, you write

506
00:44:52.119 --> 00:45:00.559
your app in a very familiar developer, very familiar syntax and developed development experience.

507
00:45:00.880 --> 00:45:09.039
Sorry, and then Quick in its
syntax, comes with the built in

508
00:45:09.199 --> 00:45:14.719
markers that you don't need to really
think about most of the time because it's

509
00:45:14.760 --> 00:45:19.639
just built in the in the syntax, which are dollar signs. Mainly,

510
00:45:19.800 --> 00:45:23.880
instead of a component function, you
have a component dollar function and that's it.

511
00:45:23.960 --> 00:45:27.719
You just have to use that.
You don't have any other choice.

512
00:45:28.079 --> 00:45:32.239
But this is a marker for the
compiler to know which functions it needs to

513
00:45:32.320 --> 00:45:39.079
extract into these packets, right like
this tiny chunks of JavaScript, and you

514
00:45:39.079 --> 00:45:45.880
can think about all these functions has
been extracted into different tiny files automatically.

515
00:45:45.599 --> 00:45:52.599
Now it's it's smarter about how to
bundle different stuff together. But conceptually you

516
00:45:52.679 --> 00:45:57.880
get this packets on the server on
build time. Okay, it happens.

517
00:45:57.880 --> 00:46:00.000
So basically what you're saying is that
you've got this thing that's kind of a

518
00:46:00.039 --> 00:46:07.000
cross between a compiler and a bundler, which does essentially a static analysis of

519
00:46:07.360 --> 00:46:13.760
the code, and the code also
includes hints or directives or instructions, so

520
00:46:13.800 --> 00:46:16.199
some of it is basically just looking
at the code, but some of it

521
00:46:16.239 --> 00:46:21.360
is looking at special directives that are
embedded within the code, like the component

522
00:46:21.440 --> 00:46:27.159
dollar that you just mentioned, and
using this information, this compiler stash bundler

523
00:46:27.199 --> 00:46:35.079
is able to break the code into
pieces that are effectively can be streamed essentially

524
00:46:35.119 --> 00:46:40.119
independently I guess of one another when
they're actually needed. Yes, And it's

525
00:46:40.199 --> 00:46:45.360
not really a bundler, it's more
of like an unbundler or an extractor,

526
00:46:45.480 --> 00:46:49.679
right Like it's the opposite of a
bundler because it just takes the code and

527
00:46:49.719 --> 00:46:55.440
knows how to break it apart into
these packets and also how to create two

528
00:46:55.480 --> 00:47:00.880
different versions, one for the server
side rendering and one for the client or

529
00:47:00.920 --> 00:47:06.280
the client that needs to be So
I use the term bundler because most of

530
00:47:06.360 --> 00:47:09.079
us, when we deploy code into
production, we are used of, we're

531
00:47:09.199 --> 00:47:15.679
used to using this thing which takes
a lot of JavaScript files, the source

532
00:47:15.719 --> 00:47:20.880
files, and then generates from them, usually a lot fewer numbers of files

533
00:47:20.880 --> 00:47:24.199
that are actually JavaScript files that are
actually delivered, you know, having really

534
00:47:24.239 --> 00:47:30.960
funky names with hashes and whatnot.
And what you're saying is, in this

535
00:47:30.039 --> 00:47:34.760
case, it's not really a bundler
because the number of files that you know,

536
00:47:35.079 --> 00:47:37.840
the sizes of the files were put
aside the number, but the sizes

537
00:47:37.880 --> 00:47:44.159
of the files that get generated are
actually often smaller than the original source code

538
00:47:44.199 --> 00:47:49.079
files that we created independently. I'm
not talking you know, all of them

539
00:47:49.119 --> 00:47:53.920
together. I'm talking independently even each
and every file, because you're just looking

540
00:47:54.000 --> 00:47:59.960
at you know, like units of
code that needs to need to be executed

541
00:48:00.239 --> 00:48:05.880
together. Yeah, yeah, exactly. So you extract all of these into

542
00:48:06.039 --> 00:48:10.760
different tiny files. And so the
reason we needed bundlers to make, like

543
00:48:10.840 --> 00:48:15.679
to concateinate everything into or to bundle
everything into you know, fewer files,

544
00:48:15.800 --> 00:48:20.440
is because of the limitations of you
know, HDP we we like, we

545
00:48:20.480 --> 00:48:23.360
didn't want to you know, load
all these files together because then it will

546
00:48:23.400 --> 00:48:28.639
get blocked, and you know,
we have a bad user experience onloading time,

547
00:48:28.719 --> 00:48:31.360
so we wanted to chunk it into
into a single download, not to

548
00:48:31.360 --> 00:48:35.679
pay the cost of the extra like
you know that. And also the fact

549
00:48:35.760 --> 00:48:38.960
that you know a lot of the
code usually works synchronously. You know,

550
00:48:39.119 --> 00:48:44.440
you have you have function A calling
function B. Then function B needs to

551
00:48:44.480 --> 00:48:50.000
be bundled with function A because the
assumption is the way that the code works

552
00:48:50.119 --> 00:48:53.360
is that they need to be able
to run together. Yeah, exactly or

553
00:48:53.559 --> 00:49:00.880
totally correct. So so so getting
back to so you so you have this

554
00:49:00.440 --> 00:49:04.760
packet on bill time, it creates
all these you know, packets, and

555
00:49:06.679 --> 00:49:10.039
it and and it creates like a
manifest of like in the basically a map

556
00:49:10.280 --> 00:49:15.719
where you know which which location you
know, like the packets map, let's

557
00:49:15.719 --> 00:49:21.079
say, and then it takes it
and when the user requests a specific route

558
00:49:22.960 --> 00:49:28.679
quick then on the server side analyze
which route it is and produces instead of

559
00:49:28.719 --> 00:49:34.320
a let's say, a static HTML
which just like a freeze frame of the

560
00:49:34.400 --> 00:49:37.760
you know, of the first frame
of the video, it creates what I

561
00:49:37.840 --> 00:49:45.440
call a smart HTML, meaning the
HTML that knows all of the interactivity points

562
00:49:45.800 --> 00:49:52.239
of the possible interactivity points in that
page. And it analyzes the this like

563
00:49:52.360 --> 00:49:59.280
packets map and realized, oh,
these packets belong to this page. So

564
00:49:59.480 --> 00:50:07.320
it create a set of instruction and
encode it into the HTML for the browser

565
00:50:07.400 --> 00:50:13.840
to know what to do next,
like how to preload these interactivity points or

566
00:50:13.920 --> 00:50:20.280
packets or necessary packets. Now,
then it sends that only that HTML over

567
00:50:20.320 --> 00:50:25.440
the wire. The user then loads
it in the client and then starts the

568
00:50:27.159 --> 00:50:30.360
next thing, which is the buffering
part like the video. Right, so

569
00:50:31.320 --> 00:50:38.239
quick spins up a service worker or
basically utilize the service worker and hance it

570
00:50:39.000 --> 00:50:45.920
off this list of the tiny packets
you know, list that it needs to

571
00:50:46.320 --> 00:50:52.960
buffer or to pre prefetch in the
background in a separate thread, right,

572
00:50:53.519 --> 00:50:57.960
so that way it won't block.
If the user wants to, you know,

573
00:50:58.440 --> 00:51:00.400
interact with the page or something like
that, it won't get blocked.

574
00:51:01.440 --> 00:51:07.159
So you basically buffer all these pieces. And then the last point of this

575
00:51:07.320 --> 00:51:14.440
metaphor or of javaslipstream is that now
when the user will interact with the page

576
00:51:15.000 --> 00:51:19.840
instead of lazy loading the piece,
like let's say it like clicks the button

577
00:51:20.079 --> 00:51:23.480
and add to the card right like
your example from before, Now instead of

578
00:51:25.039 --> 00:51:30.039
waiting for that code to load only
on interaction, the code is already there

579
00:51:30.079 --> 00:51:36.480
because of the service worker. So
then a Quick also does something that no

580
00:51:36.840 --> 00:51:42.199
other solution does, which is called
lazy execution instead of lazy loading. So

581
00:51:42.239 --> 00:51:49.079
you just execute that code on demand. And because everything in Quick is basically

582
00:51:49.079 --> 00:51:53.519
set up to work a synchronously,
that means that it could do it in

583
00:51:53.679 --> 00:52:01.280
every different point in the app,
meaning that not thing gets hydrated or loaded

584
00:52:01.320 --> 00:52:07.119
on demand when the page loads,
but every single event in the page could

585
00:52:08.039 --> 00:52:15.519
conceptually become the initial main method or
the entry point to the app to start

586
00:52:15.559 --> 00:52:20.679
the execution of just those parts of
the app. Now, Quick actually smart

587
00:52:20.760 --> 00:52:24.519
enough to also buffer the next couple
of pages, so you always get a

588
00:52:24.639 --> 00:52:30.960
smooth interaction, so just to complete
it instead of it's more so, a

589
00:52:30.039 --> 00:52:35.239
website is not like a linear video, right, It's more like a quest.

590
00:52:35.679 --> 00:52:38.119
Well, depending on the user,
you know events, yeah it you

591
00:52:38.159 --> 00:52:42.519
know, you choose your own adventure
thing, right, So if you click

592
00:52:42.559 --> 00:52:46.880
on if you start your life on
the card page, let's say, or

593
00:52:46.960 --> 00:52:52.840
you click on that button, you
will end up totally different in a different

594
00:52:52.880 --> 00:52:58.320
location, so quickly smart enough to
know how to buffer in three dimensions in

595
00:52:58.400 --> 00:53:02.280
terms of like where the user,
so they always have a smooth experience,

596
00:53:02.360 --> 00:53:08.400
just like a single page app,
but everything will be super super efficient and

597
00:53:08.639 --> 00:53:16.000
the developer won't have to think about
any manual optimization. That's the philosophy behind

598
00:53:16.079 --> 00:53:22.679
quick and behind Java's restriction that I
think that's a really important point, because

599
00:53:22.880 --> 00:53:27.639
so a couple of important points.
Actually. So one thing is actually our

600
00:53:27.760 --> 00:53:32.239
last episode that we recorded was with
the Rich Harris, the creator of Swelt,

601
00:53:32.960 --> 00:53:37.599
and it's not something that we spoke
about with him, but I recall

602
00:53:37.719 --> 00:53:45.679
him saying I think it was him
that kind of had this critique of lazyloading

603
00:53:45.840 --> 00:53:51.920
things. They said that he often
browses while he's commuting on let's say the

604
00:53:52.000 --> 00:53:55.599
subway, whether there's little or no
reception, and he opens an article and

605
00:53:55.760 --> 00:54:00.559
when it lazyloads stuff, he just
loads it before he goes on on the

606
00:54:00.599 --> 00:54:05.480
train, and then because it uses
lazy loading, by the time something is

607
00:54:05.519 --> 00:54:08.719
needed, he doesn't actually have the
reception, and then that stuff doesn't load.

608
00:54:08.800 --> 00:54:13.639
So you're saying, in a sense, you're doing lazy loading and lazy

609
00:54:13.679 --> 00:54:19.119
execution. But because you're using this
prefetching mechanism or pre loading mechanism with a

610
00:54:19.159 --> 00:54:23.800
service worker, the stuff will be
there when it's actually needed. So it's

611
00:54:23.840 --> 00:54:30.360
downloading in a non blocking way.
It's not blocking execution or responsiveness until it

612
00:54:30.400 --> 00:54:37.880
downloads. But it's also not just
being loaded lazily only just when needed.

613
00:54:37.960 --> 00:54:43.199
It's it's being loaded as soon as
possible without blocking. So that's that's a

614
00:54:43.280 --> 00:54:47.679
really important thing. And the other
important thing is when I was at WIS

615
00:54:47.719 --> 00:54:53.760
and we had one of the problems
that we had was that you know,

616
00:54:53.800 --> 00:54:58.639
WIS is a website builder and you
have like in the wigs editor, you

617
00:54:58.679 --> 00:55:04.880
could pick from hundred of different types
of components like buttons and menus and sliders

618
00:55:04.920 --> 00:55:08.000
and galleries and whatnot. And one
of the problems we had was that the

619
00:55:08.039 --> 00:55:15.239
initial implementation downloaded all the possible we
bundled together all the possible components that you

620
00:55:15.320 --> 00:55:20.360
might have on the page. Now, that kind of worked initially when wigs

621
00:55:20.400 --> 00:55:23.800
had a few dozen components, but
then wigs had a few hundred components or

622
00:55:23.840 --> 00:55:29.360
a few thousand components, and it
got to the point where it was ridiculous.

623
00:55:29.559 --> 00:55:31.440
So we had to start thinking about
how to break it up, you

624
00:55:31.480 --> 00:55:37.400
know, understanding which components go together, which components need each other, like

625
00:55:37.480 --> 00:55:40.800
for example, a menu item is
needed by a menu and so forth.

626
00:55:42.960 --> 00:55:45.400
But we effectively, we kind of
automated it, but we had to do

627
00:55:45.440 --> 00:55:50.840
all the heavy lifting ourselves, Like
you know, we as wigs. We

628
00:55:50.880 --> 00:55:53.639
could invest a lot of developer and
developer resources into it, but it was

629
00:55:53.679 --> 00:55:59.159
something that we as wigs needed to
do. We didn't get it out for

630
00:55:59.239 --> 00:56:04.679
free from the frame work. What
you're saying is that with quick you get

631
00:56:04.840 --> 00:56:09.280
all this goodness automatically. And it's
even lower than the component level. It's

632
00:56:09.320 --> 00:56:15.559
literally at the let's call it an
event handler level or function function level or

633
00:56:15.679 --> 00:56:22.639
function level that if you need that
function, that function will only will only

634
00:56:22.719 --> 00:56:29.239
be downloaded if not when it's needed. No, I'm not phrasing it correctly.

635
00:56:29.599 --> 00:56:32.800
It's bundled separately so it can be
downloaded all on its own. It

636
00:56:32.880 --> 00:56:37.719
will be and it will be downloaded
in a non blocking way so that it

637
00:56:37.760 --> 00:56:43.119
will be available when it's needed.
Yeah, you can think about it as

638
00:56:43.280 --> 00:56:47.760
eager buffering and laser execution. Okay, that's how that's that's the right,

639
00:56:47.920 --> 00:56:52.400
A cool way to phrase it.
Yeah, Yeah, because it's not so

640
00:56:52.480 --> 00:56:55.920
eigger loading is like we all like
you know that all these have this connotation

641
00:56:57.039 --> 00:57:00.199
of oh no, it will block
the website. So that's why I call

642
00:57:00.239 --> 00:57:04.679
it eager buffering. So it's it's
more obvious that it's not blocking, you

643
00:57:04.679 --> 00:57:07.960
know, the main trend and uh
and lazy execution because then yeah, we

644
00:57:08.159 --> 00:57:13.679
only execute that code because part of
the execution is also what blocking you know

645
00:57:14.360 --> 00:57:20.480
stuff, So uh yeah, that's
uh, that's so the philosophy behind quick,

646
00:57:20.599 --> 00:57:24.599
which is automatic optimization, you know
philosophy, I think it's it's one

647
00:57:24.639 --> 00:57:29.480
of the most you know, important
things in a in a technology, Like

648
00:57:29.599 --> 00:57:35.880
if you have a good philosophy,
all of your technical decisions basically are drive

649
00:57:36.320 --> 00:57:40.360
or being drived from that philosophy.
For example, implementing a feature that will

650
00:57:42.800 --> 00:57:49.559
turn something into a more manual optimized
way is against quick philosophy, which is

651
00:57:49.599 --> 00:57:55.159
automatic optimization. So we will think
really really really really hard before we'll introduce

652
00:57:55.760 --> 00:58:02.559
another you know, you know feature
into quick which will make it less automatic

653
00:58:02.920 --> 00:58:08.960
automatically optimized or auto optimized. Now
that's what like, when I think about

654
00:58:09.079 --> 00:58:13.480
you know, the future and where
things are headed in terms of like the

655
00:58:14.719 --> 00:58:19.719
different solutions I think that everybody is
working towards a future where they want to

656
00:58:20.159 --> 00:58:24.079
you know, automatically optimize as much
as possible. I think that currently quick

657
00:58:24.400 --> 00:58:30.039
in terms of the technology because it
because it didn't have the baggage from like

658
00:58:30.119 --> 00:58:36.360
you know, supporting like backpoar compatibility
and all that stuff. It was in

659
00:58:36.400 --> 00:58:40.840
a unique point to both improve the
developer experience but also make sure that things

660
00:58:40.880 --> 00:58:45.639
are being done automatically, you know, as much as possible. And that's

661
00:58:45.679 --> 00:58:52.679
why I think that Quick currently has
you know, a doorway to a much

662
00:58:52.719 --> 00:58:59.679
faster future which everything is automatically optimized
for you. And what I showed in

663
00:58:59.719 --> 00:59:07.039
my lest lecture is kind of another
epiphany that we got by thinking about how

664
00:59:07.079 --> 00:59:14.960
we can take this philosophy and this
innovative you know, paradigm shift and actually

665
00:59:15.320 --> 00:59:19.960
imagine how the future will look like
using those tools. So do you want

666
00:59:19.960 --> 00:59:22.719
to hear about like, yeah,
sure, I'd love to hear about the

667
00:59:22.760 --> 00:59:29.159
future. Does it involve Does it
involve AI taking over the world? Yes,

668
00:59:29.320 --> 00:59:32.039
of course the future is AI and
we won't have any jobs. And

669
00:59:32.119 --> 00:59:36.480
that's basically the well, well look
at it this way. You know,

670
00:59:36.960 --> 00:59:39.800
our fear today is that AI will
take our job. Our fear, like

671
00:59:39.880 --> 00:59:45.840
a few decades ago, was that
AI will will terminate us. So well

672
00:59:46.480 --> 00:59:52.760
it first it will take our jobs, then let's talk. But yeah,

673
00:59:52.880 --> 00:59:57.599
so yeah, obviously, you know, AI is a big important part of

674
00:59:57.639 --> 01:00:01.800
our future, and I think that, you know, it will be an

675
01:00:01.840 --> 01:00:07.079
interesting next couple of years to think
about you or to see the devolvement of

676
01:00:07.159 --> 01:00:14.760
frameworks and how they better comport incorporate
themselves with the use of AI and large

677
01:00:15.039 --> 01:00:19.000
language models and such. Now in
quick for example, since the Get Go

678
01:00:20.239 --> 01:00:27.360
ever, since we realized that well
things could be broken down into a function

679
01:00:27.519 --> 01:00:35.280
level and could be buffered and or
in a predictive manner, uh sort of

680
01:00:35.320 --> 01:00:43.440
say so, Mischko and the team
actually started talking about and speaking about this

681
01:00:43.679 --> 01:00:49.079
idea of what if we could you
know, getther or you know, track

682
01:00:49.400 --> 01:00:55.480
anonymously, not with any identification details
and such, only the hashes of these

683
01:00:55.519 --> 01:01:04.039
packets like for users in terms of
like which packet gets loaded before which packet,

684
01:01:04.480 --> 01:01:07.880
and that way we could take this
information, feed it to a model

685
01:01:08.440 --> 01:01:16.320
and and build the most optimized order
of packets for each page, meaning that

686
01:01:16.360 --> 01:01:22.400
if you land on the card page, everything gets buffered in the perfect way.

687
01:01:22.559 --> 01:01:29.880
So the users will always hit the
cash and not delay when the you

688
01:01:29.920 --> 01:01:35.559
know, when you need to load. So that's that's that was a dream,

689
01:01:35.800 --> 01:01:37.119
you know, a year ago.
Now it's a reality. It's called

690
01:01:37.199 --> 01:01:44.880
quick insights. Wow. Yeah,
and uh it actually has been used in

691
01:01:44.920 --> 01:01:51.480
the quick Dogs. So quick Dogs
UH is using quick Insights, which which

692
01:01:51.519 --> 01:01:55.199
is you can you know, you
can think about it and unless this needs

693
01:01:55.199 --> 01:02:00.599
to happen per website, right,
it's on a peer website level of course,

694
01:02:00.760 --> 01:02:04.760
yeah, spa website app based.
So if I'm let's say I'm using

695
01:02:04.800 --> 01:02:09.639
something like a quick city, you're
saying you're using like built in telemetry,

696
01:02:09.639 --> 01:02:15.199
as it were, to gather information
from the field about you know, that

697
01:02:15.239 --> 01:02:24.840
particular website in which order the various
UH downloaded packets are being needed, and

698
01:02:24.880 --> 01:02:30.599
then optimizing the order of delivery to
match to best match the order in which

699
01:02:30.639 --> 01:02:37.440
the packets are being used. It's
like an elevator anticipating which floor it will

700
01:02:37.440 --> 01:02:40.800
be needed at and trying to be
as close as possible to that floor by

701
01:02:40.840 --> 01:02:46.000
the time that it's needed. Yes, and and basically this is what we

702
01:02:46.119 --> 01:02:52.159
call predictive buffering, like it tries
to predict based on the average usage.

703
01:02:52.519 --> 01:02:58.159
Oh, these packets goes together with
those packets, so let's make sure that

704
01:02:58.400 --> 01:03:05.480
they are either bundled together or loaded
just right after or buffered just right one

705
01:03:05.519 --> 01:03:08.599
after the other, so they will
all be there because this is the most

706
01:03:08.760 --> 01:03:15.239
likely path that the user will take
right. So up until Quickly Insights and

707
01:03:16.360 --> 01:03:21.679
the farmak did it in sets of
euristics where you know, if it's below

708
01:03:21.719 --> 01:03:25.880
the fault, it will you know, put it after and we will buffer

709
01:03:27.119 --> 01:03:30.000
the stuff above the fault. But
now it's a reality and using that,

710
01:03:30.920 --> 01:03:36.760
you know, I I looked again
at the lecture or talk that we had

711
01:03:36.800 --> 01:03:43.639
in our meetup where Misko visited us, you know, to record the course

712
01:03:43.960 --> 01:03:49.039
on the Quick School, and we
did a meet up about quick where he

713
01:03:49.159 --> 01:03:52.320
revealed for the first time Quick City
to the world and announced that the you

714
01:03:52.360 --> 01:03:59.159
know, they build a meta firm
work in the In the end of the

715
01:03:59.199 --> 01:04:03.079
event, we had a talk by
Benjamin Greenbaum, very you know, another

716
01:04:03.119 --> 01:04:09.239
brilliant developer. H you know,
he's a core team member. No,

717
01:04:09.639 --> 01:04:18.679
the very very experienced developer who did
like half parody half truth talk about the

718
01:04:18.719 --> 01:04:24.440
future of frameworks, like how like
the framwork of twenty thirty that was like

719
01:04:24.639 --> 01:04:30.519
basically talk about and it was a
half parody because it took like a framework

720
01:04:30.639 --> 01:04:36.320
and imaginary framork called quicker, and
it showed like, you know, all

721
01:04:36.360 --> 01:04:41.199
the possibilities that what we'll do in
you know, a couple of years and

722
01:04:41.280 --> 01:04:45.280
with you know, lots of ideas
there. And he didn't I don't think

723
01:04:45.280 --> 01:04:49.760
he knew at the time that Misko
has been thinking about this like quick Insight

724
01:04:49.840 --> 01:04:54.679
thing like and thinking about how to
do that, but a lot of his

725
01:04:54.760 --> 01:05:00.519
ideas who look looked imaginary. Now
we started thinking about them as reality because

726
01:05:00.760 --> 01:05:04.400
quick Insight already works. And then
we thought, okay, we have those

727
01:05:04.400 --> 01:05:11.000
statistics, so what else could we
do with those statistics? Now, mind

728
01:05:11.039 --> 01:05:17.079
you, those are statistics based on
the function level. That means that you

729
01:05:17.119 --> 01:05:27.559
could theoretically it's not currently being worked
on, but theoretically you could produce automatic

730
01:05:28.119 --> 01:05:32.239
and tw ntests because you know the
set of actions and their order that the

731
01:05:32.360 --> 01:05:39.239
user are taking. Maybe you know, so you could potentially create or get

732
01:05:39.239 --> 01:05:44.400
to a point where you can generate
automatic and to end tests another thing that

733
01:05:44.760 --> 01:05:48.039
no developers don't like to do.
But now based on the actual user usage

734
01:05:48.639 --> 01:05:54.000
of your app and not just you
know, you making up stuff. And

735
01:05:54.119 --> 01:06:00.000
then we thought about what if we
could take those tests and use them as

736
01:06:00.039 --> 01:06:06.840
a feedball club for the AI model
to now automatically optimize your code base for

737
01:06:06.920 --> 01:06:15.320
you, meaning seeing which code parts
are not being actually used in production and

738
01:06:16.039 --> 01:06:19.800
removing them, creating an automatic A
B test with them to see if they

739
01:06:19.800 --> 01:06:24.519
are needed or not, and then
just eliminating code from the code base.

740
01:06:24.840 --> 01:06:30.079
Another AI team member that could like
you know, refector your code and all

741
01:06:30.119 --> 01:06:34.000
the technical death death that you have, you know, to refector stuff to

742
01:06:34.000 --> 01:06:38.519
make stuff cleaner. You know,
you could use all this stuff and feedball

743
01:06:38.559 --> 01:06:44.719
club based on this ability, because
again the ability of javaskip streaming to track

744
01:06:44.760 --> 01:06:51.440
stuff on the function level which wasn't
possible in an automatic way before. So

745
01:06:53.119 --> 01:06:56.440
these are the kind of stuff that
we are thinking about in terms of like

746
01:06:56.480 --> 01:06:59.320
when you think about the future of
the web and the future of the framework

747
01:06:59.719 --> 01:07:04.800
and what else we could leverage and
such. And I would love for all

748
01:07:04.840 --> 01:07:11.800
the solutions to to to have this, you know, so we could,

749
01:07:12.039 --> 01:07:15.079
like I said before, we are
all one big Javasy family of web developers.

750
01:07:15.840 --> 01:07:20.199
I want everybody to experience this automatic, you know, feeling of I

751
01:07:20.199 --> 01:07:26.039
can just focus on building the features
and doing like cool stuff in the UI

752
01:07:26.239 --> 01:07:30.800
or the server and stuff, and
not worry about all the you know,

753
01:07:30.960 --> 01:07:36.440
the stuff. So we're we're coming
on close to the end of our episode.

754
01:07:36.760 --> 01:07:41.360
Before we finished, though, there's
one issue that I would like to

755
01:07:41.440 --> 01:07:46.000
address and and hopefully we can do
it fairly quickly, even though I think

756
01:07:46.000 --> 01:07:50.280
it's a non obvious issue now I
suppose. So here's the thing. Let's

757
01:07:50.280 --> 01:07:57.440
say I'm a person listening to to
this podcast and I'm saying, Wow,

758
01:07:57.480 --> 01:08:00.840
this is really great. I'm really
excited about the vision in that these guys

759
01:08:00.840 --> 01:08:05.400
at quick have all the cool technologies
that they're creating, AI whatnot, and

760
01:08:05.480 --> 01:08:12.599
I really want to start leveraging that, especially since we already have a React

761
01:08:12.639 --> 01:08:16.640
application that is using hydration. And
if you're using hydration, then by definition,

762
01:08:17.399 --> 01:08:25.079
you have like poor startup performance or
loading performance unless you take proactive steps

763
01:08:25.079 --> 01:08:30.159
in order to remedy it. But
here's the thing. I've got this existing

764
01:08:30.159 --> 01:08:34.600
code base. It's written in React, because you know, React, like

765
01:08:34.600 --> 01:08:38.800
we said at the very beginning,
is like the King of the Hill,

766
01:08:39.319 --> 01:08:44.399
more or less like all the other
frameworks put together. And how do I

767
01:08:44.520 --> 01:08:51.600
get from this existing code base in
React to leveraging the capabilities of quick Do

768
01:08:51.720 --> 01:08:57.760
I need to wait to a new
project or is this something that I can

769
01:08:58.279 --> 01:09:01.840
gradually transition to? What? What
what steps can I take? Yeah,

770
01:09:01.920 --> 01:09:06.880
so that's a great question. And
up until now, so since the beginning,

771
01:09:06.880 --> 01:09:11.800
we had the ability of quick a
fine React components, mean you can

772
01:09:11.840 --> 01:09:16.840
feed you know, quick We have
a quick React integration package and you could

773
01:09:18.039 --> 01:09:24.600
basically get a function that takes a
React component and quick affies it, and

774
01:09:24.640 --> 01:09:30.399
that make the means that you can
like use your existing React components inside of

775
01:09:30.439 --> 01:09:35.159
your you know, quick wrapper or
quick application. Now there are other strategies

776
01:09:35.199 --> 01:09:39.920
that you can use. Uh,
so far we had the challenge of So

777
01:09:39.960 --> 01:09:45.760
we had this from the beginning,
and I helped a bunch of companies use

778
01:09:45.800 --> 01:09:50.600
this strategy in terms of like that's
the surgery that they chose to use.

779
01:09:51.479 --> 01:09:57.600
But we kept getting you know,
more and more demands too, Like people

780
01:09:57.760 --> 01:10:01.920
really wanted to take advantage of quick
in terms of like because if you do

781
01:10:01.960 --> 01:10:08.119
the quickifying thing, you still are
you know, you have like delayed let's

782
01:10:08.159 --> 01:10:12.079
say hydration, but you still are
suffering from the same you know stuff that

783
01:10:12.119 --> 01:10:18.199
you described. So what we focused
on is to work a lot hard and

784
01:10:18.239 --> 01:10:24.359
with a lot of community members to
make sure that we are building also native

785
01:10:24.399 --> 01:10:27.800
solutions too quick for a lot of
stuff, for example, a UI component

786
01:10:27.840 --> 01:10:32.159
library, which which is fully accessible
and you know has also the best of

787
01:10:32.560 --> 01:10:40.279
you know, the the developer experience
innovations that we saw from like a project

788
01:10:40.359 --> 01:10:45.640
like Shatsien. Uh So we created
quick UI in order to you know,

789
01:10:45.800 --> 01:10:50.680
remedy that and also invested time in
helping other community projects in order to make

790
01:10:50.720 --> 01:10:57.600
sure that So the first part or
first step is to quickify your existing component.

791
01:10:57.640 --> 01:11:00.960
The next step would be probably to
place them with the native to quick

792
01:11:01.439 --> 01:11:08.800
components for example, that you can
leverage the streaming ability over your app and

793
01:11:08.840 --> 01:11:14.600
slowly move. But this is now
like from from this point onwards, this

794
01:11:14.760 --> 01:11:18.319
is one major key thing that we
want to educate about, like taking all

795
01:11:18.359 --> 01:11:23.039
of the lessons learned from you know, the past year and a half of

796
01:11:23.640 --> 01:11:30.319
applications, doing that and starting to
create migration recipes on how to do this

797
01:11:30.439 --> 01:11:35.239
stuff and just like started the process. So we don't have it ready yet,

798
01:11:35.600 --> 01:11:41.840
but but yeah, that's that's definitely
one of the key things that we

799
01:11:41.960 --> 01:11:44.479
want to you know, to focus
on. So you could do that.

800
01:11:44.560 --> 01:11:47.239
You have the ability to do that
with Quickify, but we want to have

801
01:11:49.760 --> 01:11:57.199
a more optimized, let's say,
or education material because you have different strategies

802
01:11:57.279 --> 01:12:02.119
for different scenarios, no microphone tans
and how to re rep stuff and you

803
01:12:02.159 --> 01:12:05.119
know all that stuff. So yeah, that's what we're going to focus.

804
01:12:05.760 --> 01:12:12.800
I think another important point which I
mentioned was that if you're using hydra,

805
01:12:12.960 --> 01:12:16.279
if you're if you're not using hydration, if you're building let's say, a

806
01:12:16.399 --> 01:12:23.000
dashboard that is part of some sort
of I don't know, a legacy an

807
01:12:23.119 --> 01:12:27.439
enterprise, legacy application or whatnot,
and you don't you don't care so much

808
01:12:27.479 --> 01:12:32.199
about loading performance, then it's a
different story. But if you if you're

809
01:12:32.239 --> 01:12:39.039
in a place where you're leveraging hydration, you're using something like a meta framework,

810
01:12:39.039 --> 01:12:45.479
an xtras, a remix or uh
Knox or whatever, and you're using

811
01:12:45.520 --> 01:12:49.640
hydration, then you should be caring
about the hydration costs, the hydration time,

812
01:12:49.760 --> 01:12:55.439
and then you and any solution that
you might be looking at. B

813
01:12:55.560 --> 01:13:00.319
it reacts over components, be it
u islands of hydra, whatnot. All

814
01:13:00.359 --> 01:13:05.800
of them come with a certain amount
of development and cognitive overhead. So it's

815
01:13:05.840 --> 01:13:10.680
not like you're going to be making
able to make any of these transitions for

816
01:13:10.760 --> 01:13:15.600
free, and if it's going to
cost you, then you might as well

817
01:13:15.640 --> 01:13:18.319
be looking at something that's probably going
to give you the most bang for the

818
01:13:18.359 --> 01:13:25.479
buck. And you know, Quick
looks like a really good candidate in this

819
01:13:25.640 --> 01:13:30.239
regard. Now, before we finish, let's say I've listened to this podcast.

820
01:13:30.960 --> 01:13:35.159
Sounds really interesting. I want to
to kind of get involved in the

821
01:13:35.239 --> 01:13:40.399
quick community to learn about this,
you know, to be able to start

822
01:13:40.479 --> 01:13:45.840
playing with it, to get the
relevant resources and whatnot. What's the best

823
01:13:45.840 --> 01:13:50.960
way to go about it? Okay, so good question. First of all,

824
01:13:51.000 --> 01:13:55.319
to learn about it, you have
we our website now it's quick dot

825
01:13:55.359 --> 01:14:00.479
dev or we have the the free
course that I mentioned quick school dot com

826
01:14:00.199 --> 01:14:05.359
where mid mich Core goes deeper into
the details behind it and exercises and all

827
01:14:05.399 --> 01:14:10.520
that stuff. And to be involved
in the community, you go to quick

828
01:14:10.600 --> 01:14:15.600
dot dev slash chat, which will
take you to our discord. Come say

829
01:14:15.680 --> 01:14:19.800
hi. We have lots of you
know, helpful and friendly people in the

830
01:14:19.840 --> 01:14:24.479
community. If you have questions,
people will help you. Our goal now

831
01:14:24.600 --> 01:14:30.399
is to make sure that as many
companies are successful using Quick and implementing quick

832
01:14:30.640 --> 01:14:33.279
because, as you say, you
know, if you have already a lot

833
01:14:33.319 --> 01:14:40.239
of things to learn and a lot
of manual optimization to do to get in

834
01:14:40.319 --> 01:14:44.439
order to get to those performance it
will only scale. So you think you

835
01:14:44.439 --> 01:14:48.039
need to think of yourself which solution
will scale better with time in terms of

836
01:14:48.159 --> 01:14:53.399
like, you know, like when
the app will reach to fifty megabytes,

837
01:14:53.439 --> 01:14:58.159
one other megabytes and such. Would
you like to be in a position where

838
01:14:58.640 --> 01:15:02.920
you upload the video to YouTube and
then you need to manually cut the video

839
01:15:03.039 --> 01:15:08.319
on YouTube and choose which part the
you know delivers to the kind or just

840
01:15:08.520 --> 01:15:12.239
upload to YouTube and have it automatically
down for you. I think that's the

841
01:15:12.319 --> 01:15:16.800
decision that a lot of CEOs and
decision makers need to think about where they

842
01:15:16.800 --> 01:15:21.000
evaluate, you know, the next
project. So come get involved if you

843
01:15:21.039 --> 01:15:27.359
need help, d M me or
anyone on the team and we'll we'll get

844
01:15:27.800 --> 01:15:33.119
We'll get you help and yeah,
up and running and make sure that you're

845
01:15:33.159 --> 01:15:38.000
successful. And if people do want
to d M you contact you in general,

846
01:15:38.119 --> 01:15:43.680
what's the best way to find you
specifically so you can stock me in

847
01:15:43.720 --> 01:15:48.800
the street or Twitter, shy,
underscore resling or on discord. I'm always

848
01:15:48.840 --> 01:15:54.439
on Discord on the on the Quick
Discord and you could DM me there or

849
01:15:55.520 --> 01:16:00.319
yeah, Twitter or you know,
quick school or high Rest dot I and

850
01:16:00.520 --> 01:16:04.239
all the stuff that I'm involved.
So the last thing that we'll do,

851
01:16:04.960 --> 01:16:10.520
as we always do on this podcast
is the picks. Yeah, I forgot

852
01:16:10.560 --> 01:16:13.520
to remind you about it, so
but it seems that you've come prepared,

853
01:16:14.239 --> 01:16:18.640
so I'll give you a little bit
of time to prepare by starting first.

854
01:16:19.319 --> 01:16:24.399
So I don't have a lot in
the way of picks for today, so

855
01:16:24.439 --> 01:16:30.640
I have just the one thing more
or less. So I'm not really big

856
01:16:30.680 --> 01:16:36.800
into anime or stuff like that,
but it turns out that I found this

857
01:16:36.920 --> 01:16:45.680
series on Netflix, which I like, and it's actually the Wikipedia page says

858
01:16:45.720 --> 01:16:53.279
that it's an anime influenced fantasy science
fiction television series, so it's it's animated

859
01:16:53.680 --> 01:16:57.279
and it has a kind of an
anime style, but apparently it's not exactly

860
01:16:57.359 --> 01:17:02.840
anime if it's anime influenced. It's
called called My Damon, not Demons Damon.

861
01:17:03.000 --> 01:17:10.880
It's spelled d E m o N, so it's My Damon and it's

862
01:17:11.000 --> 01:17:16.720
like about this world in which,
as a result of some unexplained occurrence or

863
01:17:16.800 --> 01:17:24.520
accident or holocaust or whatever. The
monsters called daemons have kind of infiltrated our

864
01:17:24.560 --> 01:17:30.239
existence and people really lose them and
hate them. But on the other hand,

865
01:17:30.239 --> 01:17:35.960
they're very useful because they have these
kind of weird capabilities, like to

866
01:17:36.000 --> 01:17:42.720
negate gravity or do sleep or turn
invisible or stuff like that. So people

867
01:17:43.279 --> 01:17:47.920
use them. But there's this kid
who adopted one, and he actually really

868
01:17:47.960 --> 01:17:53.760
loves it for some reason. But
of course they are being chased and he's

869
01:17:54.079 --> 01:17:59.800
on the run, and it happens
in Japan. Because anime, the artwork

870
01:18:00.159 --> 01:18:06.239
is really great, uh. And
also the stories are so far are pretty

871
01:18:06.279 --> 01:18:10.640
good. I'm enjoying it. So
as I said, it's called My Damon

872
01:18:11.039 --> 01:18:16.119
and I'll put the link in the
show notes. And that's more or less

873
01:18:16.199 --> 01:18:20.800
my pick for today because I didn't
come very very prepared in this regard to

874
01:18:20.840 --> 01:18:26.319
our episode, so Shy, maybe
you can, you know, provide a

875
01:18:26.319 --> 01:18:30.920
bit more good choice. I also
wanted to pick, but I will pick

876
01:18:30.079 --> 01:18:35.439
Matt Damon. The actor is not
an anime, but it is a good

877
01:18:35.520 --> 01:18:42.479
actor. I like him. Uh. I also have a good Nestix show

878
01:18:42.560 --> 01:18:47.279
that me and my wife are watching
now. It's called The gentleman. Oh

879
01:18:47.359 --> 01:18:51.760
yeah, I actually picked it a
couple of episodes back. It's yeah,

880
01:18:51.840 --> 01:18:58.760
very very good. Yeah, it's
actually it's a it's a Guy Ritchie show

881
01:18:59.199 --> 01:19:05.560
inspired by Guy Richie movie. Yeah
yeah, yeah, yeah, it's have

882
01:19:05.720 --> 01:19:12.760
that distinct taste. We didn't.
We're now getting to the last episode of

883
01:19:12.800 --> 01:19:15.560
the you know, the first season, so no spoilers, but that's that's

884
01:19:15.600 --> 01:19:20.199
that's one of my picks. An
other pick that I want to pick is

885
01:19:20.840 --> 01:19:28.680
something about Angular. So Angular signals
and the new versions of Angular are amazing.

886
01:19:29.560 --> 01:19:33.000
You should you if you have an
Angular app, you should totally upgrade

887
01:19:33.239 --> 01:19:39.439
and use them. It makes the
development experience super great, very fun to

888
01:19:39.479 --> 01:19:43.680
work with. So yeah, I
want to give a big shout out to

889
01:19:43.720 --> 01:19:48.399
the team who worked hard on implementing
it. I wanted to also pick a

890
01:19:48.439 --> 01:19:53.960
Solid Start, which reaches you know, almost one point zero. I think

891
01:19:54.000 --> 01:20:00.520
our CEE now also a team who
worked super hard on getting there. So

892
01:20:00.560 --> 01:20:02.800
shout out to Ryan Carneato and the
team. Oh yeah, Ryan Carneato is

893
01:20:02.800 --> 01:20:06.960
a good friend. We've actually had
them on on this podcast several times.

894
01:20:08.000 --> 01:20:12.199
So if people are interested in and
you know, all the exciting things going

895
01:20:12.199 --> 01:20:15.600
on Solid, they can listen to
those episodes. We probably should have them

896
01:20:15.640 --> 01:20:19.720
on the show again as soon as
they finally released version one. Yeah,

897
01:20:19.760 --> 01:20:28.399
definitely and totally love this guy.
And and also yeah, I wanted to

898
01:20:28.880 --> 01:20:32.119
you know, re mentioned maybe some
of the stuff that I said QUICKI dot

899
01:20:32.159 --> 01:20:35.720
com, with school dot com,
all the stuff that you know you need

900
01:20:35.960 --> 01:20:42.119
in order to be successful with Quick. We now had also a big announcement

901
01:20:42.279 --> 01:20:46.359
that you know, Quick is becoming
more community driven project, meaning that we'll

902
01:20:46.399 --> 01:20:53.000
start seeing more activity and more you
know, more companies supporting Quick, and

903
01:20:53.279 --> 01:20:57.000
you know, lots of the great
and exciting things that you know, our

904
01:20:57.039 --> 01:21:01.359
community members have been asking for quite
a while we now to to see.

905
01:21:01.479 --> 01:21:05.760
So we're now we're now doing all
the stuff that we're waiting to do.

906
01:21:06.600 --> 01:21:11.960
So yeah, exciting times and I
can't wait to see what the future bring

907
01:21:12.039 --> 01:21:15.359
us. Good luck. So Shi, thank you very much for coming on

908
01:21:15.399 --> 01:21:21.479
our show. I've had lots of
fun and you know, thank you very

909
01:21:21.560 --> 01:21:25.319
much, and you know, probably
have you on again the next time.

910
01:21:25.359 --> 01:21:28.520
There's something really exciting happens with Quick, and you know, with all the

911
01:21:28.520 --> 01:21:32.640
community effort, probably exciting things are
ahead. So thank you very much,

912
01:21:33.039 --> 01:21:40.039
Thank you very much. John It
was a pleasure. Thanks bye everybody,