WEBVTT

1
00:00:00.080 --> 00:00:03.000
<v Speaker 1>Welcome to the Deep Dive. Today. We're tackling a pretty

2
00:00:03.000 --> 00:00:05.200
<v Speaker 1>big topic, JavaScript frameworks.

3
00:00:05.280 --> 00:00:07.599
<v Speaker 2>Yeah. It's a huge part of web development today for sure.

4
00:00:07.879 --> 00:00:11.359
<v Speaker 1>And we're using Vlad Philippa's book Building Your Own JavaScript

5
00:00:11.439 --> 00:00:13.320
<v Speaker 1>Framework as our main guide here.

6
00:00:13.599 --> 00:00:14.279
<v Speaker 2>That's the plan.

7
00:00:14.480 --> 00:00:17.280
<v Speaker 1>Our mission really is to cut through some of the

8
00:00:17.320 --> 00:00:20.839
<v Speaker 1>complexity and get to the core of why these frameworks

9
00:00:20.879 --> 00:00:24.399
<v Speaker 1>are so dominant and what makes them actually work right.

10
00:00:24.480 --> 00:00:26.839
<v Speaker 2>And this book is pretty recent, came out last year.

11
00:00:27.280 --> 00:00:31.480
<v Speaker 2>Vlad Philipov, he's got a ton of experience Mozilla, Stripe,

12
00:00:31.800 --> 00:00:33.039
<v Speaker 2>grunt js wow.

13
00:00:33.159 --> 00:00:34.880
<v Speaker 1>Yeah, solid background.

14
00:00:34.600 --> 00:00:38.039
<v Speaker 2>Definitely, and he's really aiming to help developers not just

15
00:00:38.280 --> 00:00:42.439
<v Speaker 2>use frameworks, but understand them deeply, maybe even build their own.

16
00:00:42.679 --> 00:00:44.039
<v Speaker 1>That's ambitious, it is.

17
00:00:44.479 --> 00:00:47.119
<v Speaker 2>And Mike Taylor from Google wrote the ForWord, which kind

18
00:00:47.159 --> 00:00:49.240
<v Speaker 2>of speaks to Vlad standing in the community.

19
00:00:49.359 --> 00:00:51.840
<v Speaker 1>Okay, cool, And for you listening, maybe you're making tech

20
00:00:51.920 --> 00:00:54.840
<v Speaker 1>choices or leveling up your skills, or maybe you're just

21
00:00:54.880 --> 00:00:57.920
<v Speaker 1>curious about like the plumbing of the modern web. This

22
00:00:58.000 --> 00:01:00.759
<v Speaker 1>deep dive should give you a solt a handle on

23
00:01:00.880 --> 00:01:04.400
<v Speaker 1>JavaScript frameworks. We'll try to keep it practical, focus on

24
00:01:04.439 --> 00:01:07.359
<v Speaker 1>the why and the what without drowning in jargon.

25
00:01:07.439 --> 00:01:08.920
<v Speaker 2>Sounds good, let's get into it.

26
00:01:09.000 --> 00:01:11.560
<v Speaker 1>Okay, So where does the book start the rise of

27
00:01:11.640 --> 00:01:12.680
<v Speaker 1>JavaScript itself?

28
00:01:12.879 --> 00:01:16.120
<v Speaker 2>Exactly? It sets the stage by looking back at JavaScript's

29
00:01:16.200 --> 00:01:19.239
<v Speaker 2>journey over twenty five years. Right, it went from just

30
00:01:19.280 --> 00:01:20.599
<v Speaker 2>simple scripting.

31
00:01:20.599 --> 00:01:22.879
<v Speaker 1>Yeah, like making text blank basically.

32
00:01:23.079 --> 00:01:27.040
<v Speaker 2>Pretty much to being this, you know, powerhouse language. It's

33
00:01:27.120 --> 00:01:30.239
<v Speaker 2>used on something like ninety eight percent of websites. That's staggering,

34
00:01:30.480 --> 00:01:31.000
<v Speaker 2>it really is.

35
00:01:31.040 --> 00:01:34.040
<v Speaker 1>You can't imagine the Web without it now. And the

36
00:01:34.079 --> 00:01:37.359
<v Speaker 1>book makes the point that frameworks became the standard way

37
00:01:37.359 --> 00:01:38.040
<v Speaker 1>to build things.

38
00:01:38.519 --> 00:01:41.400
<v Speaker 2>Millions of developers rely on them. They enable that rapid

39
00:01:41.400 --> 00:01:42.599
<v Speaker 2>development we see everywhere.

40
00:01:42.719 --> 00:01:44.120
<v Speaker 1>It's hard to argue with that, And the.

41
00:01:44.040 --> 00:01:47.239
<v Speaker 2>Book poses an interesting thought. Maybe the Web wouldn't have

42
00:01:47.319 --> 00:01:51.040
<v Speaker 2>kept up with other platforms like native apps without frameworks

43
00:01:51.079 --> 00:01:52.120
<v Speaker 2>pushing things forward.

44
00:01:52.200 --> 00:01:55.959
<v Speaker 1>Huh, that's a big claim. Why what were the early challenges?

45
00:01:56.239 --> 00:01:59.480
<v Speaker 2>Well, think about it. Early on front tend stuff was

46
00:01:59.519 --> 00:02:03.760
<v Speaker 2>often lots of repeated code, not much focus on like

47
00:02:04.159 --> 00:02:07.079
<v Speaker 2>organizing for performance or scalability.

48
00:02:06.480 --> 00:02:09.000
<v Speaker 1>Right, copy paste driven development sometimes.

49
00:02:08.719 --> 00:02:12.360
<v Speaker 2>Sometimes yeah, And deployment was often pretty basic too. Frameworks

50
00:02:12.360 --> 00:02:13.599
<v Speaker 2>brought structure.

51
00:02:13.319 --> 00:02:15.680
<v Speaker 1>And they pushed for things like a build step right

52
00:02:15.719 --> 00:02:19.840
<v Speaker 1>tools like webpack s build. Those weren't common before.

53
00:02:19.520 --> 00:02:23.120
<v Speaker 2>Not nearly as common. That build step became crucial. Package

54
00:02:23.159 --> 00:02:26.719
<v Speaker 2>managers too for handling all the dependencies, and transpilers like

55
00:02:26.759 --> 00:02:29.159
<v Speaker 2>Babble letting you use new JavaScript features sooner.

56
00:02:29.400 --> 00:02:33.400
<v Speaker 1>Okay, So frameworks sort of force the ecosystem to mature

57
00:02:33.439 --> 00:02:33.840
<v Speaker 1>in a way.

58
00:02:33.960 --> 00:02:37.000
<v Speaker 2>You could definitely say that, which brings us to the benefits.

59
00:02:37.080 --> 00:02:39.479
<v Speaker 2>The big one the book highlights is abstraction.

60
00:02:39.759 --> 00:02:42.639
<v Speaker 1>Abstraction meaning hiding complexity.

61
00:02:42.120 --> 00:02:45.400
<v Speaker 2>Pretty much providing simpler ways to do complex things. It

62
00:02:45.520 --> 00:02:49.080
<v Speaker 2>lets developers focus on the actual business logic, the features,

63
00:02:49.080 --> 00:02:50.479
<v Speaker 2>and iterate faster.

64
00:02:50.400 --> 00:02:54.280
<v Speaker 1>Gotcha like the example of asynchronous web requests before fetch

65
00:02:54.319 --> 00:02:55.400
<v Speaker 1>API was standard.

66
00:02:55.639 --> 00:02:59.000
<v Speaker 2>Oh yeah, that used to be way more complicated. Different

67
00:02:59.000 --> 00:03:03.879
<v Speaker 2>browsers handled x some LHTTP requests differently. Error handling was tricky.

68
00:03:04.400 --> 00:03:06.560
<v Speaker 2>Frameworks smoothed all that out.

69
00:03:06.719 --> 00:03:09.439
<v Speaker 1>I remember those days. It was painful totally.

70
00:03:10.039 --> 00:03:13.319
<v Speaker 2>And it's not just basic browser stuff. Frameworks help integrate

71
00:03:13.400 --> 00:03:16.280
<v Speaker 2>with databases external APIs.

72
00:03:16.000 --> 00:03:18.080
<v Speaker 1>Like graft you all integration, maybe exactly.

73
00:03:18.199 --> 00:03:21.000
<v Speaker 2>Some frameworks make that much simpler. It helps keep your

74
00:03:21.039 --> 00:03:23.120
<v Speaker 2>front end and back end talking.

75
00:03:22.919 --> 00:03:26.599
<v Speaker 1>Nicely, and presumably helps with security too. By providing standard

76
00:03:26.639 --> 00:03:27.479
<v Speaker 1>ways to do things.

77
00:03:27.599 --> 00:03:30.560
<v Speaker 2>That can be a benefit. Yeah, fewer chances for common errors.

78
00:03:31.039 --> 00:03:34.280
<v Speaker 2>Plus they help developers keep up with evolving web standards.

79
00:03:34.400 --> 00:03:37.360
<v Speaker 1>Okay, what else tooling you mentioned CLIs right?

80
00:03:37.400 --> 00:03:39.680
<v Speaker 2>Command line interfaces clies are huge.

81
00:03:39.800 --> 00:03:43.159
<v Speaker 1>Many frameworks come with one, so you type commands in

82
00:03:43.199 --> 00:03:44.479
<v Speaker 1>your terminal yep.

83
00:03:44.680 --> 00:03:46.800
<v Speaker 2>Like the Ember CLI. It can set up a whole

84
00:03:46.840 --> 00:03:51.000
<v Speaker 2>new project for you, generate boilerplate code for components or routes.

85
00:03:51.199 --> 00:03:53.039
<v Speaker 1>Ah. So it saves a lot of setup time and

86
00:03:53.159 --> 00:03:54.639
<v Speaker 1>keeps things consistent exactly.

87
00:03:54.680 --> 00:03:56.280
<v Speaker 2>It's like having a toolkit ready to go.

88
00:03:56.560 --> 00:03:59.319
<v Speaker 1>Makes sense. The book then gives specific examples, which I

89
00:03:59.319 --> 00:04:00.000
<v Speaker 1>found really helped.

90
00:04:00.680 --> 00:04:04.360
<v Speaker 2>Yeah, Comparing them really clarifies the different philosophies. They start

91
00:04:04.360 --> 00:04:09.280
<v Speaker 2>with MBERGS, which is described as opinionated, highly opinionated. It

92
00:04:09.319 --> 00:04:14.479
<v Speaker 2>makes a lot of choices for you about structure, component services, models, routers, CLI,

93
00:04:14.599 --> 00:04:16.160
<v Speaker 2>even data management with.

94
00:04:16.279 --> 00:04:18.800
<v Speaker 1>Mber data, so steeper learning curve maybe the.

95
00:04:18.720 --> 00:04:22.199
<v Speaker 2>Book suggests that. Yeah, but the payoff is supposed to

96
00:04:22.199 --> 00:04:26.560
<v Speaker 2>be consistency and guidance towards building really solid, maintainable apps,

97
00:04:27.120 --> 00:04:28.399
<v Speaker 2>especially for larger teams.

98
00:04:28.439 --> 00:04:30.439
<v Speaker 1>And it came from sprout Core originally.

99
00:04:30.639 --> 00:04:33.279
<v Speaker 2>Interesting, Yeah, it has a history. Then you've got spelt

100
00:04:33.360 --> 00:04:35.160
<v Speaker 2>Kit powered by Spelt.

101
00:04:34.800 --> 00:04:38.480
<v Speaker 1>Right the dot sveelt files everything in one place, script

102
00:04:38.720 --> 00:04:40.079
<v Speaker 1>style HTML.

103
00:04:40.360 --> 00:04:43.279
<v Speaker 2>Huh. And it's big thing is the compiler. It does

104
00:04:43.319 --> 00:04:45.480
<v Speaker 2>a lot of work before the code even hits the browser,

105
00:04:45.839 --> 00:04:48.920
<v Speaker 2>compiling those spelt components into efficient vanilla javascripts.

106
00:04:49.000 --> 00:04:51.439
<v Speaker 1>That's different. And it uses vite for tooling.

107
00:04:51.720 --> 00:04:54.040
<v Speaker 2>Yeah, vitees done for being really fast during development.

108
00:04:54.120 --> 00:04:57.279
<v Speaker 1>Okay. Then next JS that's built on React right for

109
00:04:57.360 --> 00:04:58.000
<v Speaker 1>service side.

110
00:04:57.839 --> 00:05:01.040
<v Speaker 2>Rendering primarily, Yes, SSR is a big focus. Lots of

111
00:05:01.040 --> 00:05:04.240
<v Speaker 2>built in features, especially around fetching data, very popular for

112
00:05:04.279 --> 00:05:05.879
<v Speaker 2>sites needing good SEO.

113
00:05:06.079 --> 00:05:08.560
<v Speaker 1>And NEXTJS is kind of the view equivalent.

114
00:05:08.639 --> 00:05:12.839
<v Speaker 2>Broadly speaking, Yes uses VJs. Also focuses on SSR and

115
00:05:12.879 --> 00:05:16.879
<v Speaker 2>optimizing the app experience, often using Webpack and babble behind

116
00:05:16.879 --> 00:05:17.680
<v Speaker 2>the scenes.

117
00:05:17.399 --> 00:05:20.040
<v Speaker 1>And solid start for solog ijs. What's its angle?

118
00:05:20.199 --> 00:05:23.040
<v Speaker 2>The book highlights its flexibility with rendering methods and its

119
00:05:23.040 --> 00:05:27.600
<v Speaker 2>efficient rendering using like standard browser features, real dom nodes,

120
00:05:27.680 --> 00:05:29.519
<v Speaker 2>web components.

121
00:05:28.800 --> 00:05:31.319
<v Speaker 1>Interesting and remix full stack.

122
00:05:31.480 --> 00:05:35.279
<v Speaker 2>Yeah. Remix handles frontend and back end. Very UI focused,

123
00:05:35.360 --> 00:05:39.000
<v Speaker 2>uses Typescript and React, known for its powerful routing, often

124
00:05:39.040 --> 00:05:41.319
<v Speaker 2>file based, lots of rendering options too.

125
00:05:41.480 --> 00:05:43.959
<v Speaker 1>Wow, Okay, that's quite a spectrum of approaches.

126
00:05:44.079 --> 00:05:46.319
<v Speaker 2>It really is, and the book tries to categorize the

127
00:05:46.319 --> 00:05:48.040
<v Speaker 2>common features and patterns you see.

128
00:05:47.879 --> 00:05:51.480
<v Speaker 1>Across them, like spa single page application.

129
00:05:51.120 --> 00:05:54.079
<v Speaker 2>Right where the page loads once and content updates dynamically.

130
00:05:54.279 --> 00:05:57.959
<v Speaker 1>SSR service side rendering, which we mentioned, good for SEO initial.

131
00:05:57.600 --> 00:06:01.120
<v Speaker 2>Load, CSR client side rendering, the browser does all the work.

132
00:06:01.360 --> 00:06:05.160
<v Speaker 1>SSG static site generators build all the HTML upfront, good

133
00:06:05.199 --> 00:06:06.160
<v Speaker 1>for blogs.

134
00:06:05.800 --> 00:06:09.439
<v Speaker 2>Docs exactly, And patterns like SFC single file components like

135
00:06:09.519 --> 00:06:10.480
<v Speaker 2>spelt uses and.

136
00:06:10.439 --> 00:06:14.360
<v Speaker 1>Those classic architectural patterns MVC, MVVM.

137
00:06:13.959 --> 00:06:15.680
<v Speaker 2>Model view controller, model.

138
00:06:15.480 --> 00:06:18.920
<v Speaker 1>Viewview model. Yeah, common ways to structure the code's responsibilities.

139
00:06:19.319 --> 00:06:22.199
<v Speaker 1>They're blueprints. Many frameworks adapt.

140
00:06:22.360 --> 00:06:24.720
<v Speaker 2>The book mentioned the Touto MBC project here.

141
00:06:24.800 --> 00:06:27.680
<v Speaker 1>Oh yeah. Totem vc was brilliant, simple to do app

142
00:06:28.000 --> 00:06:29.759
<v Speaker 1>built in dozens of different frameworks.

143
00:06:29.839 --> 00:06:31.560
<v Speaker 2>You could compare them side by side.

144
00:06:31.279 --> 00:06:36.560
<v Speaker 1>Exactly apples apples comparison of syntax structure performance. It was

145
00:06:36.759 --> 00:06:39.079
<v Speaker 1>incredibly useful for understanding the differences.

146
00:06:39.199 --> 00:06:41.199
<v Speaker 2>We probably need a new version of that now with

147
00:06:41.279 --> 00:06:42.399
<v Speaker 2>all the newer frameworks.

148
00:06:42.560 --> 00:06:45.240
<v Speaker 1>The book suggests that too, would be fascinating.

149
00:06:44.839 --> 00:06:48.480
<v Speaker 2>Definitely now The book also touches on back end frameworks right,

150
00:06:48.519 --> 00:06:49.439
<v Speaker 2>not just front end.

151
00:06:49.560 --> 00:06:53.399
<v Speaker 1>YEP important distinction. Frameworks aren't just for the browser. Back

152
00:06:53.480 --> 00:06:56.720
<v Speaker 1>End frameworks help build server side logic and APIs thick.

153
00:06:56.759 --> 00:06:58.240
<v Speaker 2>Express That one comes up a lot.

154
00:06:58.319 --> 00:07:02.399
<v Speaker 1>Express is huge in the no jail world, very minimal, unopinionated,

155
00:07:02.680 --> 00:07:04.800
<v Speaker 1>often a starting point you build on top of it.

156
00:07:04.879 --> 00:07:06.879
<v Speaker 2>What about others? Happy dot js?

157
00:07:06.959 --> 00:07:12.600
<v Speaker 1>Happyjs is more opinionated, convention over configuration, strong built in

158
00:07:12.639 --> 00:07:15.000
<v Speaker 1>features for things like validation sales.

159
00:07:15.040 --> 00:07:18.279
<v Speaker 2>Dot js sales is like an MVC framework built on Express.

160
00:07:18.920 --> 00:07:24.480
<v Speaker 2>Enterprise focus, RM support powerful CLISJS that sounds familiar. SGS

161
00:07:24.560 --> 00:07:29.199
<v Speaker 2>is very popular, uses Typescript, heavily structured similarly to Angular.

162
00:07:29.279 --> 00:07:33.000
<v Speaker 2>Actually good for micro services, web sockets, graph QL and

163
00:07:33.399 --> 00:07:39.600
<v Speaker 2>isjs another comprehensive typescript back end framework. RM templating routing

164
00:07:39.680 --> 00:07:40.879
<v Speaker 2>kind of an all in one solution.

165
00:07:41.040 --> 00:07:42.920
<v Speaker 1>Okay, so lots of options on the back end too,

166
00:07:43.079 --> 00:07:44.360
<v Speaker 1>and even goes beyond the web.

167
00:07:44.680 --> 00:07:48.439
<v Speaker 2>Yeah. Briefly mentions native and hardware frameworks React Nator for

168
00:07:48.519 --> 00:07:49.920
<v Speaker 2>cross platform mobile.

169
00:07:49.639 --> 00:07:52.120
<v Speaker 1>Apps build once, run on iOS and Android.

170
00:07:52.160 --> 00:07:55.600
<v Speaker 2>That's the idea Electron for desktop apps using web tech

171
00:07:55.680 --> 00:07:58.480
<v Speaker 2>like HTML, CSSGS.

172
00:07:57.480 --> 00:07:59.439
<v Speaker 1>Like Slacker vs code exactly.

173
00:07:59.240 --> 00:08:02.759
<v Speaker 2>And even Johnny for robotics programming hardware with JavaScript.

174
00:08:02.920 --> 00:08:05.759
<v Speaker 1>Ohoh, okay, JavaScript really is everywhere.

175
00:08:05.800 --> 00:08:08.879
<v Speaker 2>It's wild, and you can't talk frameworks without talking testing.

176
00:08:08.639 --> 00:08:10.319
<v Speaker 1>Right, ensuring things actually work.

177
00:08:10.399 --> 00:08:14.360
<v Speaker 2>The book mentions just Playwright Vitist as examples crucial for billing,

178
00:08:14.360 --> 00:08:17.000
<v Speaker 2>reliable apps and reliable frameworks.

179
00:08:16.519 --> 00:08:19.560
<v Speaker 1>Okay, and mentioned the STATEDJAS dot com survey is a

180
00:08:19.600 --> 00:08:20.480
<v Speaker 1>way to track trends.

181
00:08:20.800 --> 00:08:24.079
<v Speaker 2>Yeah, that survey is a great resource. The book noted

182
00:08:24.120 --> 00:08:27.319
<v Speaker 2>the twenty twenty two surveys showed maybe a slight dip

183
00:08:27.399 --> 00:08:30.279
<v Speaker 2>and reacts retention rate developers saying they'd use it again.

184
00:08:30.480 --> 00:08:33.879
<v Speaker 1>Interesting suggest the landscape is always shifting.

185
00:08:33.559 --> 00:08:37.200
<v Speaker 2>Absolutely, which is why the book emphasizes understanding the core

186
00:08:37.360 --> 00:08:42.799
<v Speaker 2>patterns that transcend specific popular frameworks. Those ideas are likely

187
00:08:42.840 --> 00:08:43.559
<v Speaker 2>to stick around.

188
00:08:43.679 --> 00:08:46.879
<v Speaker 1>That makes sense. Focus on the fundamentals. Okay, so we've

189
00:08:46.919 --> 00:08:49.120
<v Speaker 1>covered the Y and the what, Let's peel back the layers.

190
00:08:49.120 --> 00:08:53.720
<v Speaker 1>How are these things actually built? Framework organization and abstractions.

191
00:08:53.120 --> 00:08:55.879
<v Speaker 2>Right, And the book even nudges you to use debugging

192
00:08:55.960 --> 00:08:58.840
<v Speaker 2>tools like in vs code to poke around inside a

193
00:08:58.840 --> 00:09:00.600
<v Speaker 2>frameworks code and see how let's put together.

194
00:09:00.679 --> 00:09:02.360
<v Speaker 1>Get your hands dirty exactly.

195
00:09:02.960 --> 00:09:07.080
<v Speaker 2>So abstractions we mentioned them before, but they're central taking

196
00:09:07.120 --> 00:09:10.240
<v Speaker 2>complex stuff, giving it a simpler interface.

197
00:09:09.919 --> 00:09:11.759
<v Speaker 1>Hiding the messy details, and.

198
00:09:11.679 --> 00:09:15.960
<v Speaker 2>Also organizing different features into usable patterns. It lets developers

199
00:09:15.960 --> 00:09:19.960
<v Speaker 2>focus on their specific problem the business logic, not the

200
00:09:20.080 --> 00:09:21.039
<v Speaker 2>low level plumbing.

201
00:09:21.120 --> 00:09:23.039
<v Speaker 1>Cuts down on repetition complexity.

202
00:09:23.279 --> 00:09:27.039
<v Speaker 2>Right, and abstraction is a Corsis concept, not just web dev.

203
00:09:27.159 --> 00:09:30.919
<v Speaker 2>Simplifying complex systems is how we build anything sophisticated.

204
00:09:31.039 --> 00:09:32.840
<v Speaker 1>The book talks about levels of abstraction.

205
00:09:33.039 --> 00:09:37.039
<v Speaker 2>Yeah, like layers browser APIs or one level back end

206
00:09:37.120 --> 00:09:41.120
<v Speaker 2>services running on OS infrastructures. Another frameworks add their own

207
00:09:41.200 --> 00:09:41.879
<v Speaker 2>layers on top.

208
00:09:42.080 --> 00:09:45.240
<v Speaker 1>But abstractions aren't perfect right downsides good point.

209
00:09:45.879 --> 00:09:48.720
<v Speaker 2>The book mentions they might be incomplete, not cover every

210
00:09:48.799 --> 00:09:52.600
<v Speaker 2>edge case, or they might misrepresent the low level system,

211
00:09:52.600 --> 00:09:54.679
<v Speaker 2>which can be confusing if you need to debug deep

212
00:09:54.840 --> 00:09:55.399
<v Speaker 2>and being.

213
00:09:55.240 --> 00:09:58.000
<v Speaker 1>Too opinionated can limit flexibility.

214
00:09:57.320 --> 00:10:00.840
<v Speaker 2>Definitely, Like the next JSAP roads examples. Super convenient for

215
00:10:00.879 --> 00:10:04.120
<v Speaker 2>the standard case, but maybe restrictive if you want a

216
00:10:04.159 --> 00:10:05.799
<v Speaker 2>different structure. It's a tradeoff.

217
00:10:05.960 --> 00:10:09.320
<v Speaker 1>Okay, So what are these abstractions built from? In JavaScript?

218
00:10:09.480 --> 00:10:11.720
<v Speaker 2>On the front end? A lot builds on the web

219
00:10:11.759 --> 00:10:17.519
<v Speaker 2>APIs The browser provides domb bomb, cssom fetch, web sockets, storage,

220
00:10:17.559 --> 00:10:19.320
<v Speaker 2>background services, tons of them.

221
00:10:19.519 --> 00:10:22.320
<v Speaker 1>So frameworks often wrap these browser features, often.

222
00:10:22.200 --> 00:10:24.840
<v Speaker 2>Yes, or they build their own abstractions from scratch based

223
00:10:24.840 --> 00:10:26.039
<v Speaker 2>on their design goals.

224
00:10:25.759 --> 00:10:27.799
<v Speaker 1>Like the next JS nestlink example.

225
00:10:27.600 --> 00:10:32.159
<v Speaker 2>Perfect example. It simplifies creating internal links compared to a

226
00:10:32.240 --> 00:10:36.159
<v Speaker 2>basic HTML attag building on view router's capabilities, but adding

227
00:10:36.279 --> 00:10:38.159
<v Speaker 2>next specific features takes.

228
00:10:37.919 --> 00:10:41.879
<v Speaker 1>A basic tool, makes it more framework specific and convenient exactly.

229
00:10:42.039 --> 00:10:45.200
<v Speaker 2>And on the back end, no js provides its own APIs,

230
00:10:45.480 --> 00:10:48.639
<v Speaker 2>and frameworks build on those, sometimes adding custom extensions.

231
00:10:49.039 --> 00:10:52.440
<v Speaker 1>The abstraction levels vary there too, like nestjs letting you

232
00:10:52.480 --> 00:10:54.720
<v Speaker 1>swap HTTP frameworks right, you.

233
00:10:54.639 --> 00:10:57.440
<v Speaker 2>Can choose express or fastify under the hood in nests.

234
00:10:57.519 --> 00:11:00.840
<v Speaker 2>That's a pretty high level of abstraction over the server itself.

235
00:11:00.919 --> 00:11:02.240
<v Speaker 1>Events are important too.

236
00:11:02.279 --> 00:11:05.840
<v Speaker 2>Crucial responding to user clicks on the front end, handling

237
00:11:05.919 --> 00:11:09.519
<v Speaker 2>beta streams on back end. Happyjs has its event system.

238
00:11:09.919 --> 00:11:12.000
<v Speaker 2>Johnny five uses events for sensor data.

239
00:11:12.559 --> 00:11:16.000
<v Speaker 1>It's everywhere and the UI specific stuff components.

240
00:11:15.559 --> 00:11:16.879
<v Speaker 2>Yeah, the building blocks of UI.

241
00:11:17.120 --> 00:11:17.399
<v Speaker 1>Yeah.

242
00:11:17.440 --> 00:11:20.960
<v Speaker 2>The book distinguishes between nesting just putting one inside another

243
00:11:21.159 --> 00:11:23.759
<v Speaker 2>and composition designing them to work together flexibly.

244
00:11:23.879 --> 00:11:27.679
<v Speaker 1>Light cycle methods those hooks where you run code at specific.

245
00:11:27.200 --> 00:11:29.879
<v Speaker 2>Times YEP like mounted in view or use effect and

246
00:11:29.919 --> 00:11:32.879
<v Speaker 2>React frameworks manage the component life cycle and give you

247
00:11:32.919 --> 00:11:33.360
<v Speaker 2>points to.

248
00:11:33.320 --> 00:11:36.080
<v Speaker 1>Plug in routers for mapping URLs.

249
00:11:36.080 --> 00:11:39.519
<v Speaker 2>Essential for spas mapping a URL path to the right

250
00:11:39.639 --> 00:11:41.159
<v Speaker 2>component or logic.

251
00:11:41.039 --> 00:11:46.039
<v Speaker 1>And template engines mixing HTML like syntax with data.

252
00:11:45.679 --> 00:11:49.000
<v Speaker 2>Right, defining the structure and binding it to application state.

253
00:11:49.240 --> 00:11:53.840
<v Speaker 1>Okay, and the book clarifies modules, libraries and frameworks good distinction.

254
00:11:54.480 --> 00:11:59.639
<v Speaker 2>Modules are about code organization, encapsulation. Libraryes solve specific problems

255
00:11:59.720 --> 00:12:03.519
<v Speaker 2>like podash for utilities, React for UI. Frameworks provide the

256
00:12:03.519 --> 00:12:07.399
<v Speaker 2>whole structure the rules of the game, often using libraries internally.

257
00:12:07.000 --> 00:12:11.600
<v Speaker 1>Got it modules Organized libraries solve frameworks orchestrate nicely print Okay,

258
00:12:11.600 --> 00:12:14.600
<v Speaker 1>so we understand abstractions and building blocks. What about the

259
00:12:14.639 --> 00:12:17.879
<v Speaker 1>overall internal architecture? How are framework structured inside?

260
00:12:18.000 --> 00:12:22.519
<v Speaker 2>This part focuses on the patterns APIs packaging tooling, basically

261
00:12:22.519 --> 00:12:25.000
<v Speaker 2>how the framework itself is engineered, and a key point

262
00:12:25.039 --> 00:12:27.360
<v Speaker 2>is that the architecture is often designed with the framework

263
00:12:27.440 --> 00:12:28.799
<v Speaker 2>user the developer in mind.

264
00:12:28.879 --> 00:12:30.440
<v Speaker 1>Makes sense. It has to be usable.

265
00:12:30.279 --> 00:12:33.120
<v Speaker 2>Totally, so you see things like a clear directory structure,

266
00:12:33.519 --> 00:12:38.000
<v Speaker 2>separation of concerns different parts do different jobs, and well

267
00:12:38.039 --> 00:12:42.000
<v Speaker 2>defined public interfaces the APIs developers actually interact with.

268
00:12:42.360 --> 00:12:45.799
<v Speaker 1>Some frameworks are split into multiple repos like Angular.

269
00:12:45.919 --> 00:12:50.200
<v Speaker 2>Yeah for very large frameworks that helps manage complexity. Core

270
00:12:50.279 --> 00:12:53.879
<v Speaker 2>logic might be separate from the CLI tool, for instance.

271
00:12:53.720 --> 00:12:57.120
<v Speaker 1>And modules are key for organizing the frameworks on code too.

272
00:12:57.240 --> 00:13:01.720
<v Speaker 2>Absolutely the module pattern is universal form encapsulation. The technical

273
00:13:01.840 --> 00:13:06.799
<v Speaker 2>architecture then outlines the specific APIs entry points and tooling.

274
00:13:06.600 --> 00:13:09.240
<v Speaker 1>And it's all distributed as packages, usually via NPM.

275
00:13:09.399 --> 00:13:13.200
<v Speaker 2>Mostly Yes, packages contain the core logic, public, private APIs,

276
00:13:13.240 --> 00:13:16.200
<v Speaker 2>maybe build tools. The book points out some common package

277
00:13:16.200 --> 00:13:18.000
<v Speaker 2>types in modern frameworks.

278
00:13:17.519 --> 00:13:20.039
<v Speaker 1>Like a server interface package for full stack.

279
00:13:19.879 --> 00:13:23.639
<v Speaker 2>Or back end right like ne SGS adapters, NEXTJS server package,

280
00:13:23.720 --> 00:13:26.759
<v Speaker 2>feltkit adapters. They handle the connection to the deployment environment.

281
00:13:26.919 --> 00:13:29.039
<v Speaker 1>Shared packages for common utilities.

282
00:13:28.720 --> 00:13:33.720
<v Speaker 2>YEP reusable stuff like helper functions, constants, maybe HTML escaping logic.

283
00:13:33.519 --> 00:13:36.120
<v Speaker 1>Core API packages the fundamental building.

284
00:13:35.840 --> 00:13:40.559
<v Speaker 2>Blocks exactly like Angler's dependency injection system. The stuff developers used.

285
00:13:40.480 --> 00:13:42.519
<v Speaker 1>Directly developer tools packages.

286
00:13:42.159 --> 00:13:47.279
<v Speaker 2>Enhancing the dev experience, linters, formatters, debug tools integrated somehow

287
00:13:47.559 --> 00:13:51.960
<v Speaker 2>and plugin extension APIs crucial for customization, allowing users or

288
00:13:52.000 --> 00:13:55.120
<v Speaker 2>other developers to extend the framework without modifying the core.

289
00:13:55.639 --> 00:13:59.200
<v Speaker 2>Think Happy dot JS plugins or solid as integrations.

290
00:13:59.279 --> 00:14:01.200
<v Speaker 1>What about entry point Where does it all start?

291
00:14:01.360 --> 00:14:04.840
<v Speaker 2>Key concept where the framework or the application using it

292
00:14:04.879 --> 00:14:09.080
<v Speaker 2>boots up Ember's application class, nuts, dot com fig, dot

293
00:14:09.120 --> 00:14:13.559
<v Speaker 2>JS back end, bootstrap files like an ADONISJS or sjs's

294
00:14:13.600 --> 00:14:14.679
<v Speaker 2>app module.

295
00:14:14.360 --> 00:14:17.360
<v Speaker 1>And binary s executables. The cli tools we talked about YEP.

296
00:14:17.399 --> 00:14:22.240
<v Speaker 2>Scripts for building, testing, scaffolding, managing dependencies, automating the workflow.

297
00:14:21.879 --> 00:14:25.120
<v Speaker 1>Compiler, bundler, infrastructure tools like babble s built.

298
00:14:25.000 --> 00:14:28.720
<v Speaker 2>Essential, transforming and optimizing the code. For production frameworks often

299
00:14:28.720 --> 00:14:30.240
<v Speaker 2>bundle or configure.

300
00:14:29.759 --> 00:14:31.000
<v Speaker 1>These tools and types.

301
00:14:31.200 --> 00:14:35.240
<v Speaker 2>For Typescript very important if the framework uses Typescript. Exporting

302
00:14:35.279 --> 00:14:39.360
<v Speaker 2>type definitions ts files allows developers using Typescript to get

303
00:14:39.360 --> 00:14:42.360
<v Speaker 2>autocompletion and type checking. Huge productivity boost.

304
00:14:42.720 --> 00:14:45.840
<v Speaker 1>Wow. Okay, A lot goes into the internal plumbing. So

305
00:14:46.000 --> 00:14:49.679
<v Speaker 1>once it's built, how do you ensure it's well, good, usable,

306
00:14:49.720 --> 00:14:50.519
<v Speaker 1>in high quality.

307
00:14:50.799 --> 00:14:54.120
<v Speaker 2>That's the next section focuses on documentation, framework, testing, and

308
00:14:54.159 --> 00:14:57.600
<v Speaker 2>deb tooling. Documentation is first, and the book calls it

309
00:14:57.799 --> 00:15:00.399
<v Speaker 2>absolutely crucial for adoption sense.

310
00:15:00.519 --> 00:15:02.039
<v Speaker 1>If people can't figure out how to use.

311
00:15:01.960 --> 00:15:06.519
<v Speaker 2>It, they won't. So comprehensive API references good examples, maybe

312
00:15:06.559 --> 00:15:08.480
<v Speaker 2>even internal docks for contributors.

313
00:15:08.720 --> 00:15:11.639
<v Speaker 1>API references can be generated automatically.

314
00:15:11.159 --> 00:15:14.399
<v Speaker 2>Sometimes yeah from code comments using tools like jstoc or

315
00:15:14.440 --> 00:15:19.000
<v Speaker 2>type doc or written manually. Stat Site generators like Docusaurus

316
00:15:19.080 --> 00:15:22.960
<v Speaker 2>are often used to build the actual documentation websites. Viewdogs

317
00:15:23.000 --> 00:15:26.320
<v Speaker 2>and Angular are mentioned as having strong docs. Examples are

318
00:15:26.360 --> 00:15:29.679
<v Speaker 2>key to hugely important. They drastically lower the learning curve.

319
00:15:30.000 --> 00:15:32.440
<v Speaker 2>Can be in the docks or as separate code samples,

320
00:15:32.759 --> 00:15:36.720
<v Speaker 2>even for internal company frameworks. Good examples save tons of time.

321
00:15:36.600 --> 00:15:39.919
<v Speaker 1>And internal docks for contributors. Explaining how to build test

322
00:15:39.960 --> 00:15:41.000
<v Speaker 1>contribute code.

323
00:15:40.840 --> 00:15:45.200
<v Speaker 2>Essential for open source YEAH, setting contribution guidelines, coding standards,

324
00:15:45.600 --> 00:15:48.600
<v Speaker 2>Ember and Angular are again cited as good examples here.

325
00:15:48.919 --> 00:15:50.559
<v Speaker 1>Then testing the framework.

326
00:15:50.159 --> 00:15:54.679
<v Speaker 2>Itself vital making sure it's correct performance, handles edge cases

327
00:15:55.279 --> 00:15:59.919
<v Speaker 2>using testing frameworks like just playwright vitised internally.

328
00:16:00.120 --> 00:16:01.799
<v Speaker 1>What kinds of tests unit.

329
00:16:01.559 --> 00:16:06.279
<v Speaker 2>Tests for individual functions, modules and isolation, integration tests to

330
00:16:06.360 --> 00:16:09.320
<v Speaker 2>check how different parts work together. End to end tests

331
00:16:09.360 --> 00:16:12.000
<v Speaker 2>that run a whole sample application built with the framework.

332
00:16:12.120 --> 00:16:13.840
<v Speaker 1>Testing the whole workflow exactly.

333
00:16:14.159 --> 00:16:17.159
<v Speaker 2>The book gives snippets showing how Angular and NESGS might

334
00:16:17.200 --> 00:16:18.679
<v Speaker 2>test their own internal pieces.

335
00:16:18.720 --> 00:16:20.200
<v Speaker 1>Benchmarking performance too.

336
00:16:20.159 --> 00:16:25.120
<v Speaker 2>Yep, measuring API speed, rendering efficiency, how it handles large inputs,

337
00:16:25.399 --> 00:16:29.600
<v Speaker 2>both public APIs and internal micro benchmarks. Next, dot js

338
00:16:29.679 --> 00:16:31.840
<v Speaker 2>having benchmark scripts is mentioned.

339
00:16:31.639 --> 00:16:35.120
<v Speaker 1>And finally, development tooling for the framework's own development.

340
00:16:34.879 --> 00:16:38.759
<v Speaker 2>Right, things like CI systems for automated testing on every commit,

341
00:16:39.200 --> 00:16:43.639
<v Speaker 2>good source control practices with get tagging releases, managing branches,

342
00:16:44.240 --> 00:16:48.000
<v Speaker 2>and well configured package dot json files for dependencies and

343
00:16:48.080 --> 00:16:51.200
<v Speaker 2>development scripts. Linting building testing.

344
00:16:51.399 --> 00:16:54.240
<v Speaker 1>Sgs'spackage dot Jason is shown as an example of how

345
00:16:54.279 --> 00:16:55.320
<v Speaker 1>complex that can get.

346
00:16:55.519 --> 00:16:58.879
<v Speaker 2>It really ties everything together. The book wraps up this

347
00:16:58.960 --> 00:17:01.720
<v Speaker 2>part by noting that learning from the recurring patterns in

348
00:17:01.799 --> 00:17:04.480
<v Speaker 2>existing framework architectures is super valuable.

349
00:17:04.839 --> 00:17:08.359
<v Speaker 1>Okay, so we've gone deep on internals and quality. What

350
00:17:08.440 --> 00:17:11.519
<v Speaker 1>about someone actually thinking, Hey, maybe I should build a framework.

351
00:17:11.960 --> 00:17:13.440
<v Speaker 1>What considerations come first?

352
00:17:13.920 --> 00:17:17.160
<v Speaker 2>The book shifts to that practical perspective. Next starts with

353
00:17:17.319 --> 00:17:18.960
<v Speaker 2>really defining the project goals.

354
00:17:19.200 --> 00:17:22.119
<v Speaker 1>Who is this for the target audience? Right? Web apps,

355
00:17:22.400 --> 00:17:25.680
<v Speaker 1>component libraries, back end native exactly.

356
00:17:25.720 --> 00:17:30.039
<v Speaker 2>That defines the scope, then identifying the specific problem space,

357
00:17:30.200 --> 00:17:33.000
<v Speaker 2>What pain point are you solving? How is it different

358
00:17:33.119 --> 00:17:34.720
<v Speaker 2>or better than existing solutions?

359
00:17:34.759 --> 00:17:37.079
<v Speaker 1>That's the unique value proposition precisely.

360
00:17:37.400 --> 00:17:40.920
<v Speaker 2>And then come the big technical design decisions, your tech stack,

361
00:17:41.000 --> 00:17:45.400
<v Speaker 2>architectural patterns, development approach. These foundational choices shape everything.

362
00:17:45.720 --> 00:17:48.519
<v Speaker 1>Revisiting that idea of abstraction levels crucial.

363
00:17:48.680 --> 00:17:52.400
<v Speaker 2>Finding the right balance between simplifying things and keeping enough flexibility,

364
00:17:52.839 --> 00:17:56.759
<v Speaker 2>clean interfaces boosting productivity but not overly restrictive.

365
00:17:56.960 --> 00:18:01.359
<v Speaker 1>In which JavaScript environments to support browser node deno big decision.

366
00:18:01.680 --> 00:18:06.000
<v Speaker 2>Supporting multiple environments adds complexity and maintenance overhead. Need to

367
00:18:06.079 --> 00:18:07.359
<v Speaker 2>choose carefully.

368
00:18:06.960 --> 00:18:10.039
<v Speaker 1>And leveraging existing libraries. Don't reinvent the wheel.

369
00:18:10.240 --> 00:18:15.319
<v Speaker 2>Strong advice use solid libraries for common tasks routing, state management,

370
00:18:15.400 --> 00:18:19.680
<v Speaker 2>data fetching. Focus your effort on what makes your framework unique.

371
00:18:19.799 --> 00:18:24.680
<v Speaker 2>Angular using RxJS view, recommending Pinia next, building on React

372
00:18:24.720 --> 00:18:25.440
<v Speaker 2>good examples.

373
00:18:25.599 --> 00:18:27.720
<v Speaker 1>Okay, makes sense, right? Did the book gets really hands

374
00:18:27.720 --> 00:18:30.240
<v Speaker 1>on with examples building Componium test.

375
00:18:30.359 --> 00:18:32.680
<v Speaker 2>Yeah, this is where it gets concrete. Building a simple

376
00:18:32.720 --> 00:18:37.319
<v Speaker 2>testing framework starts with branding, name, logo colors. Seems small,

377
00:18:37.359 --> 00:18:40.480
<v Speaker 2>but identity matters. Choosing a unique name space.

378
00:18:40.200 --> 00:18:42.319
<v Speaker 1>Is key avoid naming collisions right.

379
00:18:42.400 --> 00:18:46.480
<v Speaker 2>Then architecting it core goal, test JS code with assertions,

380
00:18:46.599 --> 00:18:50.400
<v Speaker 2>what's needed, test runner, cross platform support, assertion types, test

381
00:18:50.400 --> 00:18:54.039
<v Speaker 2>suite interface, what's out of scope? Initially, code coverage, stubbing,

382
00:18:54.160 --> 00:18:55.799
<v Speaker 2>build system integration, keep it.

383
00:18:55.799 --> 00:18:58.960
<v Speaker 1>Focused, find the minimum viable product essentially kind of yeah.

384
00:18:59.319 --> 00:19:03.480
<v Speaker 2>Then design the overall structure the executable CLI, handling options,

385
00:19:03.519 --> 00:19:07.200
<v Speaker 2>emitting test status, respecting test life cycles, sat up, tear down.

386
00:19:07.240 --> 00:19:12.640
<v Speaker 1>And implementing executors for different environments. Node executor, browser executor exactly.

387
00:19:12.759 --> 00:19:15.720
<v Speaker 2>Node executor runs tests in node may be using worker

388
00:19:15.720 --> 00:19:20.319
<v Speaker 2>threads for isolation. Browser executor needs to control a real browser,

389
00:19:20.759 --> 00:19:21.480
<v Speaker 2>maybe using.

390
00:19:21.319 --> 00:19:24.400
<v Speaker 1>Puppeteer puppeteer let's node control Chrome yep.

391
00:19:24.680 --> 00:19:28.279
<v Speaker 2>It bridges node and the browser handles headless mode, no

392
00:19:28.400 --> 00:19:32.200
<v Speaker 2>visible UI or headful visible. Browser needs to send results

393
00:19:32.200 --> 00:19:33.519
<v Speaker 2>back from the browser to the node.

394
00:19:33.559 --> 00:19:37.480
<v Speaker 1>Runner complex and designing the API for writing tests the

395
00:19:37.559 --> 00:19:40.240
<v Speaker 1>eight function assert object life cycle methods.

396
00:19:40.400 --> 00:19:43.160
<v Speaker 2>That's the developer facing part needs to be intuitive. CT

397
00:19:43.319 --> 00:19:46.720
<v Speaker 2>defines a suite assert checks conditions, cert equaliss are true,

398
00:19:46.880 --> 00:19:50.480
<v Speaker 2>life cycle hooks like before each run before tests mocking

399
00:19:50.680 --> 00:19:52.599
<v Speaker 2>fake replaces also considered.

400
00:19:52.720 --> 00:19:56.880
<v Speaker 1>Then implementing step by step node in first internal packages, browser, infra,

401
00:19:57.119 --> 00:19:58.200
<v Speaker 1>result collection.

402
00:19:58.240 --> 00:20:01.319
<v Speaker 2>Logical progression, and the CLI needs to be well behaved,

403
00:20:01.480 --> 00:20:05.440
<v Speaker 2>follows standard conventions. Choose the right executor based on user input.

404
00:20:05.160 --> 00:20:08.359
<v Speaker 1>And testing the testing framework itself with E two E tests.

405
00:20:08.160 --> 00:20:11.960
<v Speaker 2>Meta but necessary. Ensure the whole install, import, execute workflow

406
00:20:11.960 --> 00:20:12.839
<v Speaker 2>functions correctly.

407
00:20:13.079 --> 00:20:15.599
<v Speaker 1>Okay, that's a great walkthrough for a focused tool. Then

408
00:20:15.599 --> 00:20:18.079
<v Speaker 1>it tackles a full stack framework Componium again.

409
00:20:18.200 --> 00:20:21.359
<v Speaker 2>Yep, same brand, bigger scope. Back End and front end

410
00:20:21.400 --> 00:20:24.720
<v Speaker 2>functionality starts with the back end entry point a server

411
00:20:24.799 --> 00:20:29.160
<v Speaker 2>file using Express as a foundation. Middleware routing requests parsing

412
00:20:29.279 --> 00:20:32.640
<v Speaker 2>API responses similar pattern to SGS starting point.

413
00:20:32.759 --> 00:20:34.640
<v Speaker 1>Back End routing uses Express routes.

414
00:20:35.000 --> 00:20:40.160
<v Speaker 2>Configuration handled by a config package. Supports YAML, json JS formats,

415
00:20:40.319 --> 00:20:44.240
<v Speaker 2>sensible defaults in default dot JS standard practice. THETIS integration

416
00:20:44.480 --> 00:20:49.119
<v Speaker 2>uses sqalized ORM via a dB package, loads models automatically

417
00:20:49.160 --> 00:20:52.200
<v Speaker 2>from a model's directory, shows an example query within a

418
00:20:52.279 --> 00:20:52.880
<v Speaker 2>route handler.

419
00:20:53.039 --> 00:20:55.839
<v Speaker 1>ORM simplifies database code definitely optional.

420
00:20:55.880 --> 00:21:00.279
<v Speaker 2>Graph Quel support is also mentioned for flexible APIs observability.

421
00:20:59.680 --> 00:21:02.839
<v Speaker 1>Log using a logger class based on Winston logs to

422
00:21:02.880 --> 00:21:06.359
<v Speaker 1>console and dev json files and PROD standard levels. Dot

423
00:21:06.440 --> 00:21:07.599
<v Speaker 1>info warn.

424
00:21:07.599 --> 00:21:11.000
<v Speaker 2>Error good for debugging and monitoring and developer experience.

425
00:21:11.279 --> 00:21:15.279
<v Speaker 1>A big focus a Componium CLI for in it scaffold

426
00:21:15.359 --> 00:21:20.319
<v Speaker 1>project dev, start dev server with hot reloading, create scaffold components,

427
00:21:20.759 --> 00:21:24.440
<v Speaker 1>streamlining the workflow, walks through a sample workflow, install in

428
00:21:24.440 --> 00:21:26.799
<v Speaker 1>it dev, create components, ad models, ad tests.

429
00:21:27.000 --> 00:21:29.119
<v Speaker 2>Yeah shows how a developer would use the CLI and

430
00:21:29.200 --> 00:21:32.839
<v Speaker 2>framework features mentions tools like chokodar for file watching, at

431
00:21:32.880 --> 00:21:36.359
<v Speaker 2>inquirer for interactive prompts, yards for parsing CLI arguments.

432
00:21:36.400 --> 00:21:38.640
<v Speaker 1>Okay, so that covers the back and end DX. Then

433
00:21:38.640 --> 00:21:41.359
<v Speaker 1>it switches to the front end part of the Componium.

434
00:21:40.799 --> 00:21:44.640
<v Speaker 2>Right building the UI side goals interact with the back

435
00:21:44.720 --> 00:21:49.319
<v Speaker 2>end API, provide visual interfaces, mimic features like reactivity from established.

436
00:21:48.960 --> 00:21:52.759
<v Speaker 1>Frameworks, architecture, component based views, routing.

437
00:21:52.599 --> 00:21:55.200
<v Speaker 2>Standard front end patterns. Key features discussed.

438
00:21:54.839 --> 00:21:56.960
<v Speaker 1>Component based architecture, reusable UI.

439
00:21:56.759 --> 00:22:00.480
<v Speaker 2>Pieces, reactivity, UI updates automatically when data changes, uses web

440
00:22:00.559 --> 00:22:03.039
<v Speaker 2>components and the proxy API. In this basic.

441
00:22:02.759 --> 00:22:06.920
<v Speaker 1>Example, templating defining UI structure uses lit html here for

442
00:22:06.920 --> 00:22:08.599
<v Speaker 1>writing HTML and JS.

443
00:22:08.440 --> 00:22:11.759
<v Speaker 2>Server side rendering SSR pre render on the server for performance,

444
00:22:11.880 --> 00:22:13.839
<v Speaker 2>SEO inject state.

445
00:22:13.720 --> 00:22:16.440
<v Speaker 1>Production optanizations, medification using s build.

446
00:22:16.400 --> 00:22:21.759
<v Speaker 2>Shows implementing reactive components. Reactive component class using proxy YEP

447
00:22:22.559 --> 00:22:26.839
<v Speaker 2>extends HTM element uses proxy to watch state changes. Templating

448
00:22:26.880 --> 00:22:29.559
<v Speaker 2>with lit HTML's tagged templates.

449
00:22:29.119 --> 00:22:33.240
<v Speaker 1>Defines a Componium component class combining reactivity and lit uses.

450
00:22:33.319 --> 00:22:36.440
<v Speaker 1>E S six imports handles events like ad Click.

451
00:22:36.359 --> 00:22:39.960
<v Speaker 2>Exactly shows how components are defined and used. Server serve

452
00:22:40.039 --> 00:22:42.839
<v Speaker 2>static files. SSR prerenders components.

453
00:22:42.839 --> 00:22:47.039
<v Speaker 1>Client side routing maps URLs to components, basic client views,

454
00:22:47.240 --> 00:22:48.559
<v Speaker 1>object examples.

455
00:22:48.119 --> 00:22:51.039
<v Speaker 2>Simple mapping. Yeah shows in a framework item component rendered

456
00:22:51.119 --> 00:22:54.799
<v Speaker 2>via SSR, then hydrated on the client mentions enabling prod

457
00:22:54.839 --> 00:22:56.519
<v Speaker 2>mode with noto D and V production.

458
00:22:56.799 --> 00:23:00.000
<v Speaker 1>Wow. Okay, so it really walks through building significant pieces.

459
00:23:00.079 --> 00:23:02.680
<v Speaker 1>What's the final section about maintenance In the future.

460
00:23:02.839 --> 00:23:08.240
<v Speaker 2>Crucial stuff starts with the software development life cycle SDLC planning, design, implement, test, deploy,

461
00:23:08.319 --> 00:23:12.680
<v Speaker 2>maintain applies to frameworks too. Agile is mentioned as an extension.

462
00:23:12.240 --> 00:23:15.880
<v Speaker 1>Development cycle for frameworks. Gathering user feedback is key.

463
00:23:15.839 --> 00:23:20.400
<v Speaker 2>Essential formal future definition processes like RFCs, mber U examples

464
00:23:20.759 --> 00:23:22.839
<v Speaker 2>keeping users informed about changes.

465
00:23:22.559 --> 00:23:25.119
<v Speaker 1>Release process details, change logs.

466
00:23:25.079 --> 00:23:29.079
<v Speaker 2>Need good change logs, automating them from commit messages. Commit

467
00:23:29.240 --> 00:23:33.000
<v Speaker 2>is in change sets, version INGSIMB major minor dot patch

468
00:23:33.079 --> 00:23:36.920
<v Speaker 2>versus calvert date based semantic release tool for automating simver

469
00:23:37.319 --> 00:23:38.759
<v Speaker 2>document your strategy.

470
00:23:39.039 --> 00:23:43.720
<v Speaker 1>Simplifying releases. Tools like release it, NPCD pipelines.

471
00:23:43.200 --> 00:23:48.279
<v Speaker 2>Automating testing, building, version bumping, publishing, continues, delivery via GitHub

472
00:23:48.279 --> 00:23:50.039
<v Speaker 2>actions circle ci makes it smoother.

473
00:23:50.319 --> 00:23:54.519
<v Speaker 1>Licensing open source apatche MITGPL versus proprietary.

474
00:23:53.960 --> 00:23:57.640
<v Speaker 2>Important decision early on choose al license. Dot com helps

475
00:23:57.920 --> 00:23:59.839
<v Speaker 2>consider dependency, licenses too.

476
00:24:00.039 --> 00:24:02.359
<v Speaker 1>And long term maintenance security.

477
00:24:02.000 --> 00:24:07.359
<v Speaker 2>Huge topic, document dangerous APIs, track vulnerabidities oas manage dependencies securely.

478
00:24:07.519 --> 00:24:09.799
<v Speaker 1>Dependency management is ongoing pain.

479
00:24:09.759 --> 00:24:13.119
<v Speaker 2>Can be keep track update, maybe migrade away from stale ones.

480
00:24:13.160 --> 00:24:14.799
<v Speaker 2>Minimize dependencies where possible.

481
00:24:14.839 --> 00:24:16.359
<v Speaker 1>Future coverage and deprecation.

482
00:24:16.519 --> 00:24:20.480
<v Speaker 2>Decide long term value of features. Deprecate carefully with migration paths,

483
00:24:20.599 --> 00:24:23.839
<v Speaker 2>use extension points, plugins, middleware to avoid.

484
00:24:23.640 --> 00:24:27.559
<v Speaker 1>Core blow modularity, MPM pros cons Evolving design with tech changes,

485
00:24:27.599 --> 00:24:29.920
<v Speaker 1>web components, node APIs.

486
00:24:29.400 --> 00:24:33.519
<v Speaker 2>Constant adaptation needed, good abstractions help manage change.

487
00:24:33.319 --> 00:24:37.160
<v Speaker 1>Then common themes in frameworks today, minimalism.

488
00:24:36.720 --> 00:24:41.599
<v Speaker 2>Yeah, lean, core focus, preact happy core performance improvements.

489
00:24:41.079 --> 00:24:46.200
<v Speaker 1>Constant push, faster rendering, lower resource use. Benchmarking tools help

490
00:24:46.279 --> 00:24:52.200
<v Speaker 1>compare jsframework benchmark tetch, empower, dot com Developer experience DX.

491
00:24:51.839 --> 00:24:56.240
<v Speaker 2>Big focus, better tooling, clearer APIs, easier workflows in.

492
00:24:56.200 --> 00:24:58.400
<v Speaker 1>The future, more built in tooling.

493
00:24:58.240 --> 00:25:04.640
<v Speaker 2>Likely, continued performance focus, core web vitals, more flexibility, database integrations, packaging,

494
00:25:04.680 --> 00:25:10.160
<v Speaker 2>bundling improvements, influence of browser engine changes, package management evolution.

495
00:25:10.000 --> 00:25:16.000
<v Speaker 1>And final practical considerations. Funding, time, support, reality.

496
00:25:15.640 --> 00:25:21.400
<v Speaker 2>Checks, frameworks need resources, money, sponsorship services, donations, significant time investment,

497
00:25:21.680 --> 00:25:23.079
<v Speaker 2>and user support structures.

498
00:25:23.160 --> 00:25:25.720
<v Speaker 1>Okay, that's a comprehensive lick, so let's try to wrap

499
00:25:25.720 --> 00:25:27.680
<v Speaker 1>this up. What are the main takeaways from this deep dive.

500
00:25:27.799 --> 00:25:29.839
<v Speaker 2>Well, I think it's clear that JavaScript frameworks aren't just

501
00:25:29.920 --> 00:25:34.240
<v Speaker 2>random code. They're complex systems built on careful abstractions.

502
00:25:33.640 --> 00:25:36.680
<v Speaker 1>Right, designed to speed up development, handle complexity.

503
00:25:36.440 --> 00:25:42.960
<v Speaker 2>Exactly, and they've evolved so much. Understanding they're building blocks, components, routing, state, abstraction,

504
00:25:43.359 --> 00:25:46.839
<v Speaker 2>and their architectural patterns gives you real insight into how

505
00:25:46.920 --> 00:25:48.920
<v Speaker 2>modern web development actually works.

506
00:25:49.240 --> 00:25:52.000
<v Speaker 1>And for you the listener, whether you're aiming to build

507
00:25:52.039 --> 00:25:54.920
<v Speaker 1>your own tools one day or just want to understand

508
00:25:54.920 --> 00:25:55.480
<v Speaker 1>the tech you.

509
00:25:55.519 --> 00:25:59.519
<v Speaker 2>Use better, exploring these ideas really empowers you, right, It

510
00:25:59.559 --> 00:26:02.160
<v Speaker 2>helps you make better choices, learn faster.

511
00:26:02.160 --> 00:26:05.119
<v Speaker 1>Definitely, So maybe check out some of the frameworks we mentioned,

512
00:26:05.359 --> 00:26:08.359
<v Speaker 1>dig into abstraction modularity.

513
00:26:07.880 --> 00:26:10.920
<v Speaker 2>Maybe even try building a tiny component, or look at

514
00:26:10.920 --> 00:26:13.400
<v Speaker 2>the contribution guide for an open source project to use

515
00:26:13.440 --> 00:26:14.400
<v Speaker 2>see how it's put together.

516
00:26:14.599 --> 00:26:17.200
<v Speaker 1>Yeah, this deep dive is just scratching the surface. Really,

517
00:26:17.200 --> 00:26:21.200
<v Speaker 1>it's a huge, constantly changing feel absolutely so. A final

518
00:26:21.240 --> 00:26:23.000
<v Speaker 1>thought to leave everyone with maybe.

519
00:26:22.799 --> 00:26:25.680
<v Speaker 2>Just that the web isn't standing still, so frameworks won't either.

520
00:26:26.640 --> 00:26:30.480
<v Speaker 2>Staying curious, understanding the principles behind the tools, not just

521
00:26:30.559 --> 00:26:33.960
<v Speaker 2>the tools themselves. That's probably the best way to stay

522
00:26:34.000 --> 00:26:34.759
<v Speaker 2>ahead of the curve.

523
00:26:35.119 --> 00:26:38.119
<v Speaker 1>Great point, keep learning the fundamentals. Thanks for joining us

524
00:26:38.200 --> 00:26:38.960
<v Speaker 1>for this deep dive.