WEBVTT

1
00:00:00.040 --> 00:00:03.040
<v Speaker 1>Ever feel like you're constantly playing catch up with the

2
00:00:03.080 --> 00:00:03.720
<v Speaker 1>latest tech.

3
00:00:03.879 --> 00:00:04.759
<v Speaker 2>Oh definitely.

4
00:00:04.839 --> 00:00:06.280
<v Speaker 1>One minute you think you're right in the wave, the

5
00:00:06.320 --> 00:00:08.519
<v Speaker 1>next you're wondering like, should I have learned that new

6
00:00:08.519 --> 00:00:09.560
<v Speaker 1>framework last week?

7
00:00:09.720 --> 00:00:10.960
<v Speaker 2>Yeah? It moves so fast.

8
00:00:11.000 --> 00:00:13.759
<v Speaker 1>It's a real challenge, isn't it, staying genuinely well informed

9
00:00:14.199 --> 00:00:18.480
<v Speaker 1>without just drowning in, you know, information overload totally. Well,

10
00:00:18.559 --> 00:00:20.399
<v Speaker 1>today we're hoping to help you cut through some of

11
00:00:20.440 --> 00:00:23.719
<v Speaker 1>that noise. Our deep dive today is into view js two.

12
00:00:24.399 --> 00:00:30.120
<v Speaker 1>It's a really powerful JavaScript framework that's made building reactive

13
00:00:30.160 --> 00:00:32.159
<v Speaker 1>web applications surprisingly accessible.

14
00:00:32.200 --> 00:00:33.600
<v Speaker 2>I think, yeah, it really has.

15
00:00:33.799 --> 00:00:38.079
<v Speaker 1>We're going to explore its capabilities, its core philosophy, and

16
00:00:38.560 --> 00:00:41.039
<v Speaker 1>you know what truly makes it stand out in the

17
00:00:41.439 --> 00:00:43.399
<v Speaker 1>let's face it crowded world of web development.

18
00:00:43.479 --> 00:00:46.960
<v Speaker 2>And for this deep dive, our main source is it's

19
00:00:47.079 --> 00:00:50.920
<v Speaker 2>excellent book Learning VIEWJS two by Olga Philipova, came out

20
00:00:50.960 --> 00:00:55.479
<v Speaker 2>back in December twenty sixteen, okay, and it's just a fantastic,

21
00:00:56.000 --> 00:00:58.280
<v Speaker 2>really practical guide. It takes you through everything from the

22
00:00:58.280 --> 00:01:02.000
<v Speaker 2>basics right up to building you know, complex real world apps.

23
00:01:02.240 --> 00:01:04.799
<v Speaker 1>Great, So our mission today is to really pull out

24
00:01:04.840 --> 00:01:07.159
<v Speaker 1>the most important insights from that source, we'll guide you

25
00:01:07.200 --> 00:01:13.079
<v Speaker 1>through viewjs's origins, its foundational principles, then get practical with

26
00:01:13.159 --> 00:01:16.959
<v Speaker 1>how to actually build applications, test them thoroughly which is key,

27
00:01:17.480 --> 00:01:20.239
<v Speaker 1>and finally deploy them so the world can see them.

28
00:01:20.799 --> 00:01:23.319
<v Speaker 1>All right, should we dive in, let's do it. Okay,

29
00:01:23.439 --> 00:01:27.159
<v Speaker 1>So to kick things off, what's the origin story here?

30
00:01:27.159 --> 00:01:29.840
<v Speaker 1>How did view js even come to be? What's the

31
00:01:29.879 --> 00:01:30.879
<v Speaker 1>behind the scenes tail?

32
00:01:31.159 --> 00:01:34.640
<v Speaker 2>What's actually a pretty classic story sort of necessity breeding invention.

33
00:01:34.760 --> 00:01:37.760
<v Speaker 2>Evan you the creator. He was working at Google Creative

34
00:01:37.799 --> 00:01:40.599
<v Speaker 2>Labs at the time, and he found himself needing a

35
00:01:40.640 --> 00:01:46.280
<v Speaker 2>tool for quickly prototyping large user interfaces. He looked around

36
00:01:46.319 --> 00:01:49.239
<v Speaker 2>at what was available. Then you had Angular widely used

37
00:01:49.280 --> 00:01:51.920
<v Speaker 2>but well quite heavy, yeah, and react to es was

38
00:01:52.040 --> 00:01:55.159
<v Speaker 2>just sort of starting to emerge, but often involved a

39
00:01:55.159 --> 00:02:00.000
<v Speaker 2>more complex MBC architecture, you know, model view controller layers,

40
00:02:00.200 --> 00:02:04.439
<v Speaker 2>standard pattern exactly, and those options they just felt too complex,

41
00:02:04.480 --> 00:02:07.319
<v Speaker 2>maybe too heavyweight for the kind of rapid UI prototyping

42
00:02:07.359 --> 00:02:09.680
<v Speaker 2>he needed to do. I think so Evan saw this

43
00:02:09.840 --> 00:02:14.080
<v Speaker 2>clear gap, you know, for something lightweight, flexible and really

44
00:02:14.080 --> 00:02:19.439
<v Speaker 2>focused on easy reactive data binding with reusable components. That's

45
00:02:19.479 --> 00:02:20.840
<v Speaker 2>really where view began.

46
00:02:20.840 --> 00:02:24.240
<v Speaker 1>So born from a very specific need speed in prototyping,

47
00:02:24.400 --> 00:02:26.719
<v Speaker 1>but it obviously grew way beyond that pretty quickly. Did

48
00:02:27.080 --> 00:02:29.759
<v Speaker 1>What was it about views core design that let it

49
00:02:29.800 --> 00:02:33.840
<v Speaker 1>evolve like that to handle complex, scalable applications? Yeah? How

50
00:02:33.840 --> 00:02:36.120
<v Speaker 1>do you bridge that gap from just prototyping?

51
00:02:36.240 --> 00:02:38.520
<v Speaker 2>That's a great question, and it really boils down to

52
00:02:38.560 --> 00:02:44.520
<v Speaker 2>its core philosophy simplicity and reactivity. Okay, viejs as real

53
00:02:44.639 --> 00:02:48.360
<v Speaker 2>brilliance I think lies in its almost deceptively simple approach

54
00:02:48.400 --> 00:02:52.680
<v Speaker 2>to data. It treats your models as just plain JavaScript objects.

55
00:02:52.240 --> 00:02:54.000
<v Speaker 1>Plain JavaScript objects. H Yeah.

56
00:02:54.039 --> 00:02:55.960
<v Speaker 2>And that wasn't just like a convenience thing. It was

57
00:02:56.000 --> 00:02:59.199
<v Speaker 2>almost a philosophical stand You don't need special syntax or

58
00:02:59.199 --> 00:03:02.159
<v Speaker 2>complex class or you know, an endless list of dependencies

59
00:03:02.199 --> 00:03:05.800
<v Speaker 2>just to define your data. And that drastically lowered the

60
00:03:05.800 --> 00:03:09.520
<v Speaker 2>barrier to entry. It let developers focus on the application logic,

61
00:03:09.919 --> 00:03:12.960
<v Speaker 2>not wrestling with framework stuff, which I mean that's a

62
00:03:13.080 --> 00:03:15.919
<v Speaker 2>huge part of why it gained traction so fast. Makes sense,

63
00:03:15.960 --> 00:03:20.400
<v Speaker 2>And just to clarify some key terms here reactivity and VIEWJS.

64
00:03:20.400 --> 00:03:24.039
<v Speaker 2>That refers to the immediate propagation of any changes to

65
00:03:24.080 --> 00:03:26.319
<v Speaker 2>your data straight to the view layer, so.

66
00:03:26.400 --> 00:03:28.560
<v Speaker 1>Data changes, UI updates.

67
00:03:28.400 --> 00:03:33.159
<v Speaker 2>Instantly instantly exactly. And components they are like self contained

68
00:03:33.240 --> 00:03:36.120
<v Speaker 2>Lego bucks for your app, little pieces with their own

69
00:03:36.199 --> 00:03:39.240
<v Speaker 2>data and view designed to be reused everywhere.

70
00:03:38.840 --> 00:03:40.719
<v Speaker 1>Okay, reusable building blocks.

71
00:03:40.840 --> 00:03:43.719
<v Speaker 2>And two way data binding means changes in the data

72
00:03:43.800 --> 00:03:46.800
<v Speaker 2>model update the view and crucially, changes in the view

73
00:03:46.879 --> 00:03:49.879
<v Speaker 2>like typing in an input field, they reflect right back

74
00:03:49.879 --> 00:03:50.759
<v Speaker 2>into the data model.

75
00:03:51.120 --> 00:03:54.520
<v Speaker 1>That seamless feedback loop precisely. That clarity around data flow

76
00:03:54.560 --> 00:03:58.400
<v Speaker 1>and component sounds really powerful. So with that foundation, how

77
00:03:58.439 --> 00:04:02.120
<v Speaker 1>does the book actually show view dots in action? What

78
00:04:02.159 --> 00:04:03.479
<v Speaker 1>are the practical example? Right?

79
00:04:03.479 --> 00:04:06.520
<v Speaker 2>So the book introduces two very practical applications. There's a

80
00:04:06.560 --> 00:04:08.319
<v Speaker 2>shopping list and a Pomodoro.

81
00:04:07.919 --> 00:04:09.439
<v Speaker 1>Timer okay, classic examples.

82
00:04:09.639 --> 00:04:12.400
<v Speaker 2>Yeah, And the shopping list one is particularly good because

83
00:04:12.439 --> 00:04:16.439
<v Speaker 2>the book first implements it using jQuery for comparison exactly,

84
00:04:16.560 --> 00:04:19.439
<v Speaker 2>and then it does it with VIEWJS, and that side

85
00:04:19.480 --> 00:04:23.759
<v Speaker 2>by side really highlights views elegance and frankly efficiency in

86
00:04:23.800 --> 00:04:27.480
<v Speaker 2>handling things like adding and removing items dynamically compared to

87
00:04:27.560 --> 00:04:30.600
<v Speaker 2>what can become pretty verbose jQuery code I can imagine.

88
00:04:30.639 --> 00:04:33.199
<v Speaker 2>And then the Pomodoro pimer app you know, based on

89
00:04:33.240 --> 00:04:35.120
<v Speaker 2>that time management technique with work intervals.

90
00:04:35.240 --> 00:04:37.120
<v Speaker 1>Yeah, focus bursts, right.

91
00:04:37.000 --> 00:04:40.319
<v Speaker 2>It uses VJs for managing the countdowns, handling all the

92
00:04:40.319 --> 00:04:44.639
<v Speaker 2>state changes, starting, pausing, stopping the timer, switching between work

93
00:04:44.680 --> 00:04:47.480
<v Speaker 2>and rest. It's a great way to see that reactivity

94
00:04:47.519 --> 00:04:48.600
<v Speaker 2>concept really working.

95
00:04:48.759 --> 00:04:51.079
<v Speaker 1>That sound like great learning tools. Yeah. Does the book

96
00:04:51.160 --> 00:04:54.839
<v Speaker 1>also mention how VJs is used out in the wild

97
00:04:55.519 --> 00:04:58.680
<v Speaker 1>beyond these examples, any like big projects or companies using it?

98
00:04:58.759 --> 00:05:01.560
<v Speaker 2>Oh? Absolutely, Yeah. The source points to some really impressive

99
00:05:01.560 --> 00:05:04.720
<v Speaker 2>real world projects that adopted view, which really speaks volumes

100
00:05:04.759 --> 00:05:08.360
<v Speaker 2>about its practicality and scalability Wiku. Well we're talking big

101
00:05:08.439 --> 00:05:14.040
<v Speaker 2>names like Grammarly's online editor uses it, Optimizedly's website testing service.

102
00:05:14.079 --> 00:05:17.120
<v Speaker 2>There's filter Blend, which is a CSS playground, push silver

103
00:05:17.360 --> 00:05:21.600
<v Speaker 2>and invoice service, and also Adera, a Ukrainian online educational

104
00:05:21.639 --> 00:05:25.439
<v Speaker 2>project where the author Olga Philipova is actually the CTO.

105
00:05:25.680 --> 00:05:26.519
<v Speaker 2>They use view too.

106
00:05:26.759 --> 00:05:30.000
<v Speaker 1>Grammarly and Optimizedly. Those are huge. Yeah. That definitely shows

107
00:05:30.040 --> 00:05:33.639
<v Speaker 1>it's not just for small projects or learning. It's clearly

108
00:05:33.920 --> 00:05:38.680
<v Speaker 1>robust enough for serious production grade stuff, no question. Okay,

109
00:05:38.720 --> 00:05:40.959
<v Speaker 1>so we've seen it in action. Now let's get under

110
00:05:40.959 --> 00:05:44.399
<v Speaker 1>the hood a bit what makes VIEWJS work its magic?

111
00:05:44.480 --> 00:05:47.399
<v Speaker 1>What are the the underlying mechanics right?

112
00:05:47.560 --> 00:05:51.120
<v Speaker 2>So, fundamentally, VIEWJS is deeply rooted in the model view

113
00:05:51.399 --> 00:05:54.439
<v Speaker 2>view model architectural pattern or MVVM MVVM okay, and the

114
00:05:54.519 --> 00:05:56.959
<v Speaker 2>view model part that acts as the sort of clever bridge.

115
00:05:57.399 --> 00:06:01.199
<v Speaker 2>It enables declarative data binding between raw data model and

116
00:06:01.240 --> 00:06:02.120
<v Speaker 2>the user interface.

117
00:06:02.160 --> 00:06:04.720
<v Speaker 1>The view declarative meaning you just say what you want,

118
00:06:04.800 --> 00:06:05.240
<v Speaker 1>not how.

119
00:06:05.079 --> 00:06:07.680
<v Speaker 2>To update it exactly. You declare the relationship, and the

120
00:06:07.759 --> 00:06:11.680
<v Speaker 2>view model handles the synchronization. Now that magic of the

121
00:06:11.720 --> 00:06:15.600
<v Speaker 2>instant updates, that's powered by JavaScript's object dot defined property,

122
00:06:15.680 --> 00:06:18.839
<v Speaker 2>specifically its gutters and setters ah.

123
00:06:18.800 --> 00:06:20.920
<v Speaker 1>The built in JavaScript features right.

124
00:06:21.040 --> 00:06:23.920
<v Speaker 2>And what's crucial here is that view isn't constantly like

125
00:06:24.360 --> 00:06:28.279
<v Speaker 2>rechecking everything the way some older frameworks did. Instead, when

126
00:06:28.319 --> 00:06:31.560
<v Speaker 2>you change a piece of data, View's internal watchers are

127
00:06:31.639 --> 00:06:35.600
<v Speaker 2>immediately alerted. They pinpoint exactly what needs updating in the UI.

128
00:06:35.759 --> 00:06:39.480
<v Speaker 2>So it's targeted efficient, very efficient. And here's where things

129
00:06:39.480 --> 00:06:44.079
<v Speaker 2>got really interesting. A major evolution in View two point

130
00:06:44.160 --> 00:06:46.399
<v Speaker 2>zero compared to one point zero was the shift to

131
00:06:46.680 --> 00:06:47.639
<v Speaker 2>a virtual dom.

132
00:06:47.879 --> 00:06:49.160
<v Speaker 1>Right. I've heard that term.

133
00:06:49.240 --> 00:06:52.319
<v Speaker 2>View one point zho directly manipulated the real browser dom,

134
00:06:52.519 --> 00:06:55.279
<v Speaker 2>which could you know, get slow sometimes, but moving to

135
00:06:55.319 --> 00:06:57.879
<v Speaker 2>a virtual dom and view two point zero that was

136
00:06:57.920 --> 00:07:01.480
<v Speaker 2>the key unlock. Also, Mike, i'reating this lightweight blueprint of

137
00:07:01.519 --> 00:07:04.439
<v Speaker 2>your UI in memory. View could figure out the absolute

138
00:07:04.480 --> 00:07:07.600
<v Speaker 2>minimum changes needed and then applied just those changes to

139
00:07:07.639 --> 00:07:09.040
<v Speaker 2>the real browser dom.

140
00:07:09.199 --> 00:07:12.480
<v Speaker 1>So it minimizes the actual slow DOM updates exactly.

141
00:07:12.560 --> 00:07:14.800
<v Speaker 2>It turned what used to be a performance bottleneck into

142
00:07:14.839 --> 00:07:18.319
<v Speaker 2>a massive advantage. It allowed for building really complex dynamic

143
00:07:18.399 --> 00:07:23.120
<v Speaker 2>interfaxes without constantly worrying about performance hits. It wasn't just faster,

144
00:07:23.399 --> 00:07:25.279
<v Speaker 2>it made certain kinds of UIs feasible.

145
00:07:25.519 --> 00:07:28.040
<v Speaker 1>That virtual dom sounds like a genuine game change of

146
00:07:28.079 --> 00:07:31.759
<v Speaker 1>then it really was. Speaking of performance and architecture, How

147
00:07:31.759 --> 00:07:35.399
<v Speaker 1>does viejs stack up against the other big players like

148
00:07:36.120 --> 00:07:37.040
<v Speaker 1>React in Angular.

149
00:07:37.160 --> 00:07:39.600
<v Speaker 2>Good question. Let's start with React in view because they

150
00:07:39.600 --> 00:07:42.279
<v Speaker 2>share quite a bit. Okay, both use a virtual dom,

151
00:07:42.519 --> 00:07:45.680
<v Speaker 2>both are built around reusable components, and both are fundamentally

152
00:07:45.720 --> 00:07:46.639
<v Speaker 2>about reactivity.

153
00:07:46.839 --> 00:07:48.839
<v Speaker 1>Similar core ideas very similar.

154
00:07:49.199 --> 00:07:51.879
<v Speaker 2>A key difference though, often comes down to how you

155
00:07:51.920 --> 00:07:58.279
<v Speaker 2>create components. React famously embraces this everything is JavaScript idea,

156
00:07:58.319 --> 00:08:00.399
<v Speaker 2>often using jsx.

157
00:08:00.120 --> 00:08:03.399
<v Speaker 1>Right that htmail in javascripts and text exactly now.

158
00:08:03.639 --> 00:08:06.920
<v Speaker 2>View can use JSX too, but it's more common practice.

159
00:08:06.959 --> 00:08:09.879
<v Speaker 2>The sort of idiomatic way is to structure components with

160
00:08:10.000 --> 00:08:14.879
<v Speaker 2>distinct template, script and style blocks inside a single dot viewfile, which.

161
00:08:14.759 --> 00:08:17.519
<v Speaker 1>Might feel more familiar to folks coming from traditional web dev.

162
00:08:17.600 --> 00:08:20.839
<v Speaker 2>It often does, yeah now learning curve wise, View is

163
00:08:20.839 --> 00:08:23.240
<v Speaker 2>often described as like out of the blue, simple to

164
00:08:23.360 --> 00:08:25.800
<v Speaker 2>just start using. You can drop it into an existing

165
00:08:25.839 --> 00:08:29.600
<v Speaker 2>page with plain JavaScript. React, on the other hand, typically

166
00:08:29.720 --> 00:08:32.679
<v Speaker 2>requires a bit more initial investment in learning JSX and

167
00:08:32.759 --> 00:08:36.600
<v Speaker 2>modern JavaScript features like e S twenty fifteen classes and erowfunctions,

168
00:08:36.639 --> 00:08:38.519
<v Speaker 2>though those are standard now anyway.

169
00:08:38.279 --> 00:08:41.000
<v Speaker 1>Got it and performance performance.

170
00:08:40.480 --> 00:08:43.519
<v Speaker 2>Wise benchmarks at the time showed View two point zero

171
00:08:43.519 --> 00:08:46.559
<v Speaker 2>is actually even faster than React in many scenarios.

172
00:08:46.559 --> 00:08:49.759
<v Speaker 1>Interesting. Okay, what about Angular versus View right?

173
00:08:49.919 --> 00:08:53.399
<v Speaker 2>The main difference there is that View is significantly less

174
00:08:53.440 --> 00:08:57.279
<v Speaker 2>opinionated than both Angular one and Angular two were, or.

175
00:08:57.240 --> 00:09:00.360
<v Speaker 1>Are less opinionated, meaning more flexible yea.

176
00:09:00.360 --> 00:09:04.320
<v Speaker 2>Less prescriptive about how you structure your entire application. Also,

177
00:09:04.440 --> 00:09:07.960
<v Speaker 2>Angular ones specifically used a technique called dirty checking.

178
00:09:08.120 --> 00:09:10.279
<v Speaker 1>Dirty checking sounds messy.

179
00:09:10.159 --> 00:09:12.279
<v Speaker 2>Yeah, well, it meant that every time something might have

180
00:09:12.360 --> 00:09:14.840
<v Speaker 2>changed in the scope, Angular had to reevaluate all the

181
00:09:14.879 --> 00:09:18.039
<v Speaker 2>watchers to see what needed updating. With lots of watchers,

182
00:09:18.240 --> 00:09:22.440
<v Speaker 2>that could impact performance. Okay, views approach using object dot

183
00:09:22.440 --> 00:09:26.600
<v Speaker 2>defined property is more direct. When a specific property changes,

184
00:09:26.720 --> 00:09:31.080
<v Speaker 2>only that property's watcher gets triggered and reevaluated, much more efficient,

185
00:09:31.240 --> 00:09:32.639
<v Speaker 2>especially in complex apps.

186
00:09:32.879 --> 00:09:36.639
<v Speaker 1>That makes sense. That less opinionated aspect sounds really appealing

187
00:09:36.720 --> 00:09:38.679
<v Speaker 1>for developers who like flexibility.

188
00:09:38.799 --> 00:09:40.639
<v Speaker 2>It's definitely one of its big draws.

189
00:09:40.879 --> 00:09:43.919
<v Speaker 1>Okay, let's circle back to those core building blocks, components

190
00:09:43.919 --> 00:09:46.360
<v Speaker 1>and data binding. Can we get into the nitty gritty

191
00:09:46.360 --> 00:09:48.120
<v Speaker 1>details of how they work in practice?

192
00:09:48.200 --> 00:09:52.039
<v Speaker 2>Absolutely so. Components, as we said, are these self contained units.

193
00:09:52.120 --> 00:09:54.440
<v Speaker 2>They have their own data scope, their own methods. They

194
00:09:54.440 --> 00:09:58.600
<v Speaker 2>can access global application scope, but they encapsulate their own logic.

195
00:09:58.840 --> 00:09:59.399
<v Speaker 1>Right now.

196
00:09:59.440 --> 00:10:05.080
<v Speaker 2>A critical point, especially for components their data and l properties.

197
00:10:05.120 --> 00:10:08.440
<v Speaker 2>The element they mount to must be functions that return

198
00:10:08.480 --> 00:10:11.279
<v Speaker 2>an object, not direct objects themselves.

199
00:10:11.360 --> 00:10:12.759
<v Speaker 1>Okay, why is that so critical?

200
00:10:12.919 --> 00:10:16.120
<v Speaker 2>It's vital to prevent shared state issues when you reuse

201
00:10:16.159 --> 00:10:19.360
<v Speaker 2>a component. Imagine you have a counter component used in

202
00:10:19.440 --> 00:10:23.360
<v Speaker 2>multiple places. If data was just an object, every instance

203
00:10:23.399 --> 00:10:25.360
<v Speaker 2>would share the exact same counter variable.

204
00:10:25.440 --> 00:10:28.559
<v Speaker 1>Oh right, Clicking one counter would increment them all chaos.

205
00:10:28.639 --> 00:10:32.799
<v Speaker 2>Exactly. Making data a function ensures each component instance gets

206
00:10:32.840 --> 00:10:34.919
<v Speaker 2>its own fresh copy of the data state.

207
00:10:35.159 --> 00:10:36.559
<v Speaker 1>Got it. That's a key detail.

208
00:10:36.879 --> 00:10:40.159
<v Speaker 2>And view offers a really elegant way to organize these

209
00:10:40.440 --> 00:10:44.519
<v Speaker 2>single file components. These are files ending in dot feustways. Yeah.

210
00:10:44.639 --> 00:10:48.200
<v Speaker 2>They let you bundle a component's HTML template, its JavaScript logic,

211
00:10:48.399 --> 00:10:51.080
<v Speaker 2>and its CSS styles altogether in one file.

212
00:10:51.600 --> 00:10:52.639
<v Speaker 1>That sounds really clean.

213
00:10:52.960 --> 00:10:56.519
<v Speaker 2>It is. It improves readability, makes components easier to manage,

214
00:10:56.679 --> 00:11:00.360
<v Speaker 2>and it also enables cool development features like hot relf loading.

215
00:11:00.559 --> 00:11:04.279
<v Speaker 2>And you can easily use preprocessors like SaaS for CSS

216
00:11:04.679 --> 00:11:06.080
<v Speaker 2>or PUG for HTML.

217
00:11:06.679 --> 00:11:09.960
<v Speaker 1>Nice. Okay, what about the different ways to actually bind

218
00:11:10.159 --> 00:11:11.039
<v Speaker 1>data to the UI?

219
00:11:11.399 --> 00:11:14.120
<v Speaker 2>Right? If you gives you several techniques, The most basic

220
00:11:14.320 --> 00:11:17.480
<v Speaker 2>is interpolation using the double curly braces.

221
00:11:17.159 --> 00:11:19.399
<v Speaker 1>Like the handlebar syntax exactly.

222
00:11:19.639 --> 00:11:22.240
<v Speaker 2>That's for one way binding, just displaying data values in

223
00:11:22.279 --> 00:11:25.480
<v Speaker 2>the DOM. And inside those braces you can use full

224
00:11:25.559 --> 00:11:26.840
<v Speaker 2>JavaScript expressions and.

225
00:11:26.840 --> 00:11:29.159
<v Speaker 1>Filters expressions like math yeah like.

226
00:11:29.120 --> 00:11:31.879
<v Speaker 2>Mouth output just twenty five. Or you can use custom

227
00:11:31.879 --> 00:11:34.440
<v Speaker 2>filters to format data right there in the template, maybe

228
00:11:34.480 --> 00:11:37.039
<v Speaker 2>a lowercase filter or a left pad filter for numbers.

229
00:11:37.080 --> 00:11:38.519
<v Speaker 2>You can even chain them together.

230
00:11:38.360 --> 00:11:39.320
<v Speaker 1>Handy for formatting.

231
00:11:39.720 --> 00:11:44.240
<v Speaker 2>Very Then you have directives. These are special attributes you

232
00:11:44.240 --> 00:11:48.039
<v Speaker 2>add to HTML elements, always prefixed with V They apply

233
00:11:48.159 --> 00:11:51.399
<v Speaker 2>reactive behavior okay, like v model exactly. V model is

234
00:11:51.440 --> 00:11:54.480
<v Speaker 2>the key one for two way data binding. You typically

235
00:11:54.600 --> 00:11:58.320
<v Speaker 2>use it on form inputs like input select, text area,

236
00:11:59.360 --> 00:12:02.960
<v Speaker 2>user types, something. The data updates, data changes, the input

237
00:12:03.000 --> 00:12:04.279
<v Speaker 2>field updates, but back and forth.

238
00:12:04.279 --> 00:12:04.519
<v Speaker 1>Clop.

239
00:12:04.840 --> 00:12:08.000
<v Speaker 2>Right. Then there's v bind, which you often see shortened

240
00:12:08.000 --> 00:12:11.200
<v Speaker 2>to just a colon like dot src or dot class.

241
00:12:11.240 --> 00:12:15.200
<v Speaker 2>Ah the shorthand hold, Yeah, that's for one way binding attributes,

242
00:12:15.399 --> 00:12:18.279
<v Speaker 2>binding data to an attribute, like setting an image source

243
00:12:18.360 --> 00:12:21.759
<v Speaker 2>dynamically or toggling CSS classes based on data.

244
00:12:21.840 --> 00:12:24.240
<v Speaker 1>Okay, data flowing into the attribute correct.

245
00:12:24.320 --> 00:12:26.879
<v Speaker 2>Then you have v if and v show for conditional rendering.

246
00:12:27.080 --> 00:12:28.080
<v Speaker 1>Right, what's the difference there?

247
00:12:28.080 --> 00:12:31.279
<v Speaker 2>Again, both hyder show elements based on a condition, but

248
00:12:31.639 --> 00:12:34.440
<v Speaker 2>v if actually adds or completely removes the element from

249
00:12:34.480 --> 00:12:37.480
<v Speaker 2>the dom physically gone physically gone, which has a higher

250
00:12:37.519 --> 00:12:40.000
<v Speaker 2>initial cost if the condition changes, but might be better

251
00:12:40.039 --> 00:12:42.519
<v Speaker 2>if it rarely toggles. V show, on the other hand,

252
00:12:42.559 --> 00:12:45.759
<v Speaker 2>just toggles the CSS display none property, so.

253
00:12:45.720 --> 00:12:47.679
<v Speaker 1>The element is always there, just hidden.

254
00:12:47.559 --> 00:12:51.320
<v Speaker 2>Exactly, lower initial cost, always rendered, so it's often better

255
00:12:51.320 --> 00:12:53.200
<v Speaker 2>for things you toggle frequently.

256
00:12:52.799 --> 00:12:54.399
<v Speaker 1>Like tabs. Okay, good distinction.

257
00:12:54.559 --> 00:12:57.360
<v Speaker 2>And finally, V four is super useful for iterating over

258
00:12:57.519 --> 00:13:01.039
<v Speaker 2>arrays or objects. To render lists. You can loop through

259
00:13:01.120 --> 00:13:04.159
<v Speaker 2>data and render and lie for each item, or even

260
00:13:04.240 --> 00:13:06.919
<v Speaker 2>render instances of other custom view components.

261
00:13:07.080 --> 00:13:11.759
<v Speaker 1>Dynamically generating lists very common, extremely common. Those directives really

262
00:13:11.799 --> 00:13:14.360
<v Speaker 1>show off views reactive power. But you know, as apps

263
00:13:14.399 --> 00:13:19.240
<v Speaker 1>get bigger, managing all that state across loads of components,

264
00:13:19.799 --> 00:13:21.480
<v Speaker 1>that sounds like it could get messy fast.

265
00:13:21.519 --> 00:13:24.120
<v Speaker 2>Oh, it absolutely can, and that is precisely the problem

266
00:13:24.200 --> 00:13:28.440
<v Speaker 2>that viex solves. The wix VX is View's official centralized

267
00:13:28.559 --> 00:13:32.399
<v Speaker 2>state management architecture. It's inspired by patterns you might know

268
00:13:32.480 --> 00:13:35.720
<v Speaker 2>like flux or reducts from the React world, right, but

269
00:13:35.759 --> 00:13:39.080
<v Speaker 2>it's generally described as having a much gentler learning curve.

270
00:13:39.639 --> 00:13:42.399
<v Speaker 2>The book calls it easier to understand and to use.

271
00:13:42.720 --> 00:13:44.840
<v Speaker 1>Easier is good. How does it work well?

272
00:13:44.919 --> 00:13:47.480
<v Speaker 2>The book uses this great analogy think of the human

273
00:13:47.519 --> 00:13:50.879
<v Speaker 2>body and brain. Your brain in this analogy is the

274
00:13:51.000 --> 00:13:53.919
<v Speaker 2>viewx store. It is the single source of truth for

275
00:13:54.000 --> 00:13:57.919
<v Speaker 2>your applications. Global state things shared across many components.

276
00:13:58.039 --> 00:13:59.720
<v Speaker 1>The central control exactly.

277
00:14:00.159 --> 00:14:02.600
<v Speaker 2>Now, your components think of them like your hands or

278
00:14:02.600 --> 00:14:05.360
<v Speaker 2>your stomach. They are bound to the state, but they

279
00:14:05.360 --> 00:14:07.559
<v Speaker 2>can only read it directly. They can't just, you know,

280
00:14:07.799 --> 00:14:09.960
<v Speaker 2>directly change how hungry the body feels.

281
00:14:10.279 --> 00:14:12.879
<v Speaker 1>My hand can't decide I'm not hungry anymore precisely.

282
00:14:13.240 --> 00:14:17.519
<v Speaker 2>Instead, components dispatch actions to the brain the store. Hey

283
00:14:17.559 --> 00:14:20.559
<v Speaker 2>I touched something hot, or hey food arrived.

284
00:14:20.320 --> 00:14:22.200
<v Speaker 1>Okay, sending signals right.

285
00:14:22.279 --> 00:14:26.519
<v Speaker 2>These actions can be asynchronous, maybe fetch data, then actions

286
00:14:26.559 --> 00:14:30.000
<v Speaker 2>trigger mutations. Mutations are the only way to actually change

287
00:14:30.000 --> 00:14:32.879
<v Speaker 2>the state, and crucially, they have to be synchronous.

288
00:14:33.039 --> 00:14:34.360
<v Speaker 1>Synchronous. Why is that important?

289
00:14:34.440 --> 00:14:37.480
<v Speaker 2>It makes tracking changes much easier. You know exactly when

290
00:14:37.679 --> 00:14:39.960
<v Speaker 2>and how the state changed because it happens in one

291
00:14:40.080 --> 00:14:43.799
<v Speaker 2>predictable step. This whole structured approach prevents components from just

292
00:14:43.919 --> 00:14:47.559
<v Speaker 2>randomly changing global state, which makes things way easier to

293
00:14:47.600 --> 00:14:48.720
<v Speaker 2>debug and maintain.

294
00:14:49.000 --> 00:14:52.000
<v Speaker 1>I see a clear predictable flow exactly.

295
00:14:52.080 --> 00:14:55.960
<v Speaker 2>So, the key parts of a Vieux store are the

296
00:14:56.039 --> 00:15:01.200
<v Speaker 2>state itself, which is just your centralized data object, mutations,

297
00:15:01.200 --> 00:15:04.480
<v Speaker 2>which are those synchronous functions that change the state. Components

298
00:15:04.519 --> 00:15:08.559
<v Speaker 2>commit mutations, mutations, got it getters, which are like computed

299
00:15:08.600 --> 00:15:12.240
<v Speaker 2>properties for your store's state. They let you derive state

300
00:15:12.440 --> 00:15:16.519
<v Speaker 2>or calculate values based on the state without actually changing.

301
00:15:16.200 --> 00:15:19.039
<v Speaker 1>It by calculating the total price from items.

302
00:15:18.720 --> 00:15:23.559
<v Speaker 2>In a card state, perfect example. And finally, actions these

303
00:15:23.559 --> 00:15:27.120
<v Speaker 2>can handle asynchronous stuff like calling an API. Once they

304
00:15:27.159 --> 00:15:30.159
<v Speaker 2>have the data or finish their logic, they then commit

305
00:15:30.279 --> 00:15:35.120
<v Speaker 2>mutations to update the state. Components dispatch actions, dispatch actions

306
00:15:35.120 --> 00:15:35.919
<v Speaker 2>commit mutations.

307
00:15:36.039 --> 00:15:39.840
<v Speaker 1>Okay, So this whole structure state, mutations, getters, actions sounds

308
00:15:39.879 --> 00:15:42.320
<v Speaker 1>like it brings a lot of discipline, especially to bigger projects.

309
00:15:42.440 --> 00:15:45.559
<v Speaker 2>It really does. It creates this predictable data flow in

310
00:15:45.639 --> 00:15:48.480
<v Speaker 2>a complex app. Trying to figure out where some piece

311
00:15:48.519 --> 00:15:51.320
<v Speaker 2>of state change can be a nightmare. If components are

312
00:15:51.360 --> 00:15:52.519
<v Speaker 2>modifying things.

313
00:15:52.279 --> 00:15:53.639
<v Speaker 1>Directly, yeah, I've been there.

314
00:15:53.799 --> 00:15:57.320
<v Speaker 2>Fux centralizes it. You know what the state is, how

315
00:15:57.360 --> 00:16:01.360
<v Speaker 2>it changes only via mutations and when triggered by actions.

316
00:16:01.919 --> 00:16:05.559
<v Speaker 2>That clarity is massive for debugging, collaboration.

317
00:16:06.279 --> 00:16:09.360
<v Speaker 1>Just keeping things same makes total sense. Okay. So beyond

318
00:16:09.480 --> 00:16:12.679
<v Speaker 1>views core and VIEWX, what if you need some really

319
00:16:13.240 --> 00:16:17.000
<v Speaker 1>specific custom functionality or want to integrate a third party

320
00:16:17.039 --> 00:16:20.399
<v Speaker 1>library smoothly? How do developers handle that?

321
00:16:20.399 --> 00:16:23.679
<v Speaker 2>That's where views plugins system really shines. Plugins are basically

322
00:16:23.759 --> 00:16:26.960
<v Speaker 2>a way to add global level functionality. Global level yeah

323
00:16:27.000 --> 00:16:31.360
<v Speaker 2>things like adding global methods or properties, custom directives, filters,

324
00:16:31.679 --> 00:16:34.960
<v Speaker 2>or even adding methods directly to view instances themselves, things

325
00:16:35.000 --> 00:16:37.759
<v Speaker 2>that aren't tied to just one component. For a plug

326
00:16:37.759 --> 00:16:39.559
<v Speaker 2>in to work, it just needs to provide an install

327
00:16:39.600 --> 00:16:40.080
<v Speaker 2>method that.

328
00:16:40.120 --> 00:16:42.440
<v Speaker 1>View calls okay, an install method right.

329
00:16:42.600 --> 00:16:45.000
<v Speaker 2>The book gives a couple of great examples. First, using

330
00:16:45.039 --> 00:16:49.399
<v Speaker 2>an existing plug in view resource a for HTTP requests exactly,

331
00:16:49.440 --> 00:16:51.639
<v Speaker 2>it shows how to integrate that plug in to let

332
00:16:51.639 --> 00:16:54.080
<v Speaker 2>the shopping list app talk to a back end API

333
00:16:54.159 --> 00:16:57.840
<v Speaker 2>fetching lists, creating items, updating, deleting using a simple tool

334
00:16:57.879 --> 00:16:58.759
<v Speaker 2>called Jason Server.

335
00:16:58.960 --> 00:17:00.840
<v Speaker 1>Jason Server it's super handy.

336
00:17:00.840 --> 00:17:03.240
<v Speaker 2>I lets you spin up a fake rest API really quickly,

337
00:17:03.360 --> 00:17:06.119
<v Speaker 2>just using a JSON file as your database. Great for

338
00:17:06.200 --> 00:17:10.000
<v Speaker 2>development and examples like this. Oh. Then the book also

339
00:17:10.079 --> 00:17:12.799
<v Speaker 2>walks you through creating a custom plug in for the

340
00:17:12.839 --> 00:17:16.279
<v Speaker 2>Pomodoro app. It shows how to build a noise generator plug.

341
00:17:16.000 --> 00:17:18.119
<v Speaker 1>In noise generator like white.

342
00:17:17.839 --> 00:17:21.400
<v Speaker 2>Noise exactly, white pink or brown noise to play during

343
00:17:21.400 --> 00:17:24.799
<v Speaker 2>the work intervals, and the plugin provides methods to control

344
00:17:24.839 --> 00:17:30.359
<v Speaker 2>it start, pause, stop, which are then managed through viewx mutations,

345
00:17:30.720 --> 00:17:32.519
<v Speaker 2>integrating neatly with the app state.

346
00:17:32.880 --> 00:17:36.279
<v Speaker 1>That's a great example of extending functionality building your own

347
00:17:36.279 --> 00:17:36.640
<v Speaker 1>plug in.

348
00:17:36.759 --> 00:17:38.160
<v Speaker 2>It really shows the flexibility.

349
00:17:38.279 --> 00:17:41.559
<v Speaker 1>Okay, so you've built these cool apps, maybe added some plugins,

350
00:17:42.119 --> 00:17:44.319
<v Speaker 1>but how do you make sure they actually work reliably

351
00:17:44.559 --> 00:17:47.039
<v Speaker 1>and you know, don't break when you change something later?

352
00:17:47.319 --> 00:17:48.160
<v Speaker 1>Let's talk testing.

353
00:17:48.279 --> 00:17:52.599
<v Speaker 2>Yes, testing absolutely paramount. The book covers the two main pillars,

354
00:17:53.039 --> 00:17:55.720
<v Speaker 2>unit tests and end to end E two E testing.

355
00:17:55.480 --> 00:17:57.519
<v Speaker 1>Unit tests first, what's the focus there?

356
00:17:57.799 --> 00:18:00.720
<v Speaker 2>Unit tests focus on testing the small TuS pieces of

357
00:18:00.759 --> 00:18:05.920
<v Speaker 2>your code in isolation, individual functions, methods, or components. The

358
00:18:05.960 --> 00:18:09.400
<v Speaker 2>book emphasizes they help us to identify failures and algorithms

359
00:18:09.400 --> 00:18:12.400
<v Speaker 2>in logic, They improve the code quality by forcing you

360
00:18:12.480 --> 00:18:15.759
<v Speaker 2>to write testable code, and crucially, they prevent future changes

361
00:18:15.759 --> 00:18:16.559
<v Speaker 2>from breaking.

362
00:18:16.359 --> 00:18:19.039
<v Speaker 1>The functionality right, catching regressions exactly.

363
00:18:19.400 --> 00:18:22.880
<v Speaker 2>The tools mentioned are pretty standard. Karma as a test runner,

364
00:18:23.200 --> 00:18:26.720
<v Speaker 2>Mocha as the testing framework, Chry for assertions checking if

365
00:18:26.759 --> 00:18:30.359
<v Speaker 2>things are correct, and sign On for creating mocks and stubs,

366
00:18:30.759 --> 00:18:33.839
<v Speaker 2>mox and steps. Yeah, ways to fake dependencies, like if

367
00:18:33.880 --> 00:18:36.599
<v Speaker 2>you're testing a component that calls VUX, you don't want

368
00:18:36.680 --> 00:18:39.119
<v Speaker 2>to involve the real viewx store. You mock it to

369
00:18:39.160 --> 00:18:40.880
<v Speaker 2>control its behavior just for the test.

370
00:18:41.039 --> 00:18:41.359
<v Speaker 1>Okay.

371
00:18:41.680 --> 00:18:44.599
<v Speaker 2>The book gives a good example testing of UX mutation

372
00:18:45.160 --> 00:18:47.880
<v Speaker 2>like a D shopping list. It shows how a test

373
00:18:47.960 --> 00:18:50.960
<v Speaker 2>might initially fail if the mutation doesn't say validate the

374
00:18:51.000 --> 00:18:53.680
<v Speaker 2>input properly. You write the test. It fails, You fix

375
00:18:53.720 --> 00:18:56.559
<v Speaker 2>the code. The test passes, that cycle improves the code.

376
00:18:56.720 --> 00:18:59.920
<v Speaker 2>It also mentions code coverage, a metric showing what percentage

377
00:18:59.960 --> 00:19:02.279
<v Speaker 2>of your code is actually covered by your tests.

378
00:19:02.279 --> 00:19:05.079
<v Speaker 1>Right, aiming for high coverage. Okay, what about end to

379
00:19:05.200 --> 00:19:05.720
<v Speaker 1>end testing?

380
00:19:06.160 --> 00:19:08.400
<v Speaker 2>So end to end E t E testing is different.

381
00:19:08.640 --> 00:19:11.559
<v Speaker 2>It tests the whole flow of the application from a

382
00:19:11.640 --> 00:19:13.200
<v Speaker 2>user's perspective.

383
00:19:12.839 --> 00:19:15.000
<v Speaker 1>Like simulating a real user clicking.

384
00:19:14.759 --> 00:19:18.480
<v Speaker 2>Around exactly no mocks allowed here. Usually you test the

385
00:19:18.480 --> 00:19:22.720
<v Speaker 2>integrated system the front end UI interacting with the real

386
00:19:22.960 --> 00:19:26.359
<v Speaker 2>or near reel back end. It verifies that everything works

387
00:19:26.359 --> 00:19:30.359
<v Speaker 2>together correctly. The book uses Nightwatch dot js, which is

388
00:19:30.400 --> 00:19:33.720
<v Speaker 2>a JavaScript framework that drives Selenium webdriver.

389
00:19:33.440 --> 00:19:35.799
<v Speaker 1>Selenia okay, the browser automation.

390
00:19:35.480 --> 00:19:38.000
<v Speaker 2>Tool right now. A common challenge with E two E

391
00:19:38.119 --> 00:19:41.000
<v Speaker 2>tests is running them in environments without a screen, like

392
00:19:41.000 --> 00:19:43.960
<v Speaker 2>a continuous integration server. Travis CI is mentioned.

393
00:19:43.759 --> 00:19:46.279
<v Speaker 1>A servers don't usually have monitors.

394
00:19:45.920 --> 00:19:48.359
<v Speaker 2>Exactly, so how do you run a browser test? The

395
00:19:48.359 --> 00:19:51.880
<v Speaker 2>solution presented as a tool called XVFB, the x virtual

396
00:19:51.920 --> 00:19:55.640
<v Speaker 2>frame buffer. It basically creates a fake in memory display

397
00:19:55.720 --> 00:19:58.319
<v Speaker 2>that the browser can render to tricking it into thinking

398
00:19:58.359 --> 00:19:58.680
<v Speaker 2>there's a.

399
00:19:58.680 --> 00:20:00.000
<v Speaker 1>Screen clever workaround.

400
00:20:00.079 --> 00:20:02.039
<v Speaker 2>It works really well for CI environments.

401
00:20:02.240 --> 00:20:05.720
<v Speaker 1>Okay, so we've built it, We've tested it rigorously, unit tests,

402
00:20:05.839 --> 00:20:09.079
<v Speaker 1>E two E tests. What's the final step getting it

403
00:20:09.119 --> 00:20:12.039
<v Speaker 1>out there for people to actually use? Deployment? Right?

404
00:20:12.079 --> 00:20:15.359
<v Speaker 2>Software deployment. The book defines it simply as all of

405
00:20:15.400 --> 00:20:18.440
<v Speaker 2>the activities that make a software system available for use,

406
00:20:19.039 --> 00:20:22.240
<v Speaker 2>and it details a really nice continuous deployment process for

407
00:20:22.319 --> 00:20:23.160
<v Speaker 2>the example apps.

408
00:20:23.240 --> 00:20:25.480
<v Speaker 1>It continues deployment meaning automated.

409
00:20:25.640 --> 00:20:28.519
<v Speaker 2>Yeah, setting up an automated pipeline from code commit to

410
00:20:28.559 --> 00:20:31.759
<v Speaker 2>live application. It makes the whole process much smoother and

411
00:20:31.880 --> 00:20:33.000
<v Speaker 2>less error prone.

412
00:20:33.079 --> 00:20:35.079
<v Speaker 1>What tools does it use for that pipeline?

413
00:20:35.319 --> 00:20:39.839
<v Speaker 2>It describes a three step process. One GitHub for hosting

414
00:20:39.880 --> 00:20:45.160
<v Speaker 2>the code repository pretty standard. Two Travis CI for continuous integration.

415
00:20:45.720 --> 00:20:49.440
<v Speaker 2>Travis automatically runs your tests, unit and ETOE every time

416
00:20:49.480 --> 00:20:51.759
<v Speaker 2>you push code to your main branch like master. If

417
00:20:51.759 --> 00:20:53.519
<v Speaker 2>the test pass it gives a green.

418
00:20:53.400 --> 00:20:55.079
<v Speaker 1>Light, so quality check built.

419
00:20:54.799 --> 00:20:58.559
<v Speaker 2>In absolutely and three Heroku, which is a cloud platform

420
00:20:58.920 --> 00:21:01.720
<v Speaker 2>use for continuous deploy. You can figure it so that

421
00:21:01.799 --> 00:21:04.680
<v Speaker 2>after a successful build and test run on TRAVISCI, if

422
00:21:04.680 --> 00:21:09.079
<v Speaker 2>Travis says okay, Heroku automatically takes the latest code, builds

423
00:21:09.079 --> 00:21:12.039
<v Speaker 2>the production version, and deploys it, making it live on

424
00:21:12.079 --> 00:21:12.440
<v Speaker 2>the web.

425
00:21:12.640 --> 00:21:16.799
<v Speaker 1>Wow, that's slick code. Push to live app automatically.

426
00:21:16.880 --> 00:21:19.400
<v Speaker 2>It is that feeling when you merge a feature and

427
00:21:19.440 --> 00:21:23.279
<v Speaker 2>a few minutes later it's live. It's pretty addictive and

428
00:21:23.319 --> 00:21:25.400
<v Speaker 2>this pipeline makes it almost frictionless.

429
00:21:25.880 --> 00:21:29.240
<v Speaker 1>Are there any specific configurations needed for say.

430
00:21:29.440 --> 00:21:33.039
<v Speaker 2>Heroku, Yeah, a few things. You typically need to move

431
00:21:33.079 --> 00:21:36.720
<v Speaker 2>some development only dependencies into the main dependency section in

432
00:21:36.759 --> 00:21:40.039
<v Speaker 2>your package dot json file so Heroku installs them. You

433
00:21:40.079 --> 00:21:42.640
<v Speaker 2>need a post install script and package dot jason that

434
00:21:42.680 --> 00:21:45.720
<v Speaker 2>tells Heroku how to build your app like running NPM

435
00:21:45.799 --> 00:21:48.640
<v Speaker 2>run build okay, and usually need a small serve file

436
00:21:48.720 --> 00:21:52.400
<v Speaker 2>like server dot js using Express, a popular noe js framework,

437
00:21:52.640 --> 00:21:55.039
<v Speaker 2>and a start script in package dot jason to tell

438
00:21:55.079 --> 00:21:57.799
<v Speaker 2>Heroku how to actually run your built application and serve

439
00:21:57.799 --> 00:22:00.920
<v Speaker 2>the static files right. Because Heroka needs to run something

440
00:22:01.079 --> 00:22:04.279
<v Speaker 2>exactly for the shopping list app. It even integrates Jason

441
00:22:04.319 --> 00:22:07.160
<v Speaker 2>Server into this setup, so the same deployed application serves

442
00:22:07.160 --> 00:22:10.319
<v Speaker 2>both the viewfront end and its own little back end API.

443
00:22:10.240 --> 00:22:12.319
<v Speaker 1>A fully self contained deployable unit.

444
00:22:12.519 --> 00:22:15.680
<v Speaker 2>Pretty much. It creates that full automated pipeline code desh

445
00:22:15.720 --> 00:22:16.720
<v Speaker 2>test to desk deploy.

446
00:22:17.160 --> 00:22:20.359
<v Speaker 1>That's a truly comprehensive journey we've mapped out from the

447
00:22:20.400 --> 00:22:24.720
<v Speaker 1>initial idea and core concepts all the way to a tested, deployed,

448
00:22:25.039 --> 00:22:29.160
<v Speaker 1>production ready application. Amazing. Looking ahead just a bit, what

449
00:22:29.240 --> 00:22:32.359
<v Speaker 1>was next for VIEWJS, even beyond the timeframe of this book.

450
00:22:32.559 --> 00:22:33.640
<v Speaker 1>How did it keep evolving?

451
00:22:33.759 --> 00:22:36.319
<v Speaker 2>Well, it's important to remember as the book emphasizes that

452
00:22:36.480 --> 00:22:40.000
<v Speaker 2>View two point zero itself was a major refactor that

453
00:22:40.079 --> 00:22:43.799
<v Speaker 2>shnift to the lightweight virtual dom structure we talked about. Yeah,

454
00:22:43.880 --> 00:22:48.079
<v Speaker 2>that brought huge performance gains. The book quotes benchmarks showing

455
00:22:48.079 --> 00:22:50.960
<v Speaker 2>its performance beats everything at that time. So I View

456
00:22:50.960 --> 00:22:53.880
<v Speaker 2>two was already a big leap forward. Okay, But looking

457
00:22:53.920 --> 00:22:57.279
<v Speaker 2>even further, the book mentions weeks weeks Yeah, a framework

458
00:22:57.279 --> 00:22:59.599
<v Speaker 2>from ali Baba that allows you to write view inspired

459
00:22:59.599 --> 00:23:03.480
<v Speaker 2>component and render them as native mobile applications for iOS

460
00:23:03.519 --> 00:23:04.680
<v Speaker 2>and Android.

461
00:23:04.240 --> 00:23:07.200
<v Speaker 1>Whoa so using view concepts for native mobile exactly.

462
00:23:07.240 --> 00:23:09.920
<v Speaker 2>It hints at views ambition expanding beyond just the web.

463
00:23:10.359 --> 00:23:12.599
<v Speaker 2>The creator, Evan You even said the goal was for

464
00:23:12.720 --> 00:23:17.160
<v Speaker 2>view inspired to become viewpowered native apps that cross platform.

465
00:23:16.799 --> 00:23:19.799
<v Speaker 1>Vision interesting, taking the viewaid to mobile.

466
00:23:20.119 --> 00:23:22.160
<v Speaker 2>And for people who are using View one point zero.

467
00:23:22.440 --> 00:23:25.200
<v Speaker 2>The book also notes that there was a migration guide

468
00:23:25.240 --> 00:23:27.759
<v Speaker 2>and even a helper tool provided by the View team

469
00:23:28.000 --> 00:23:30.079
<v Speaker 2>to make upgrading to two point zero smoother.

470
00:23:30.400 --> 00:23:32.039
<v Speaker 1>That shows good community.

471
00:23:31.559 --> 00:23:35.759
<v Speaker 2>Support Definitely making transitions easier is always appreciated.

472
00:23:36.039 --> 00:23:39.000
<v Speaker 1>What an incredible deep dive this has been. Seriously, we've

473
00:23:39.039 --> 00:23:44.000
<v Speaker 1>gone from the foundational ideas of viewjs its reactivity, through

474
00:23:44.039 --> 00:23:49.119
<v Speaker 1>building components, managing state with viex, using plugins, testing everything thoroughly,

475
00:23:49.599 --> 00:23:52.960
<v Speaker 1>and finally deploying these complex reactive web apps out into

476
00:23:52.960 --> 00:23:55.920
<v Speaker 1>the world. It feels like we've covered the entire life cycle.

477
00:23:56.079 --> 00:23:59.400
<v Speaker 2>We really have. But you know, this deep dive, it

478
00:23:59.440 --> 00:24:02.680
<v Speaker 2>isn't really the end of your journey with viewjas. It's truly,

479
00:24:02.799 --> 00:24:05.039
<v Speaker 2>as the book suggests, just the beginning.

480
00:24:05.279 --> 00:24:07.400
<v Speaker 1>Ah, the learning never stops exactly.

481
00:24:07.720 --> 00:24:10.640
<v Speaker 2>You now have all the fundamental tools and the knowledge

482
00:24:10.680 --> 00:24:13.839
<v Speaker 2>you need to keep exploring to enhance these applications, maybe

483
00:24:13.920 --> 00:24:16.000
<v Speaker 2>build your own, make them your own thing.

484
00:24:16.480 --> 00:24:18.400
<v Speaker 1>So what kind of enhancements could someone try?

485
00:24:18.640 --> 00:24:21.440
<v Speaker 2>Oh? Loads? Think about the shopping list app. You could

486
00:24:21.440 --> 00:24:24.920
<v Speaker 2>add authentication, right, so users have their own private lists.

487
00:24:25.079 --> 00:24:26.000
<v Speaker 1>Yeah, that's a big one.

488
00:24:26.119 --> 00:24:30.519
<v Speaker 2>Or inline editing for item names, a clear checked items button,

489
00:24:31.079 --> 00:24:35.519
<v Speaker 2>maybe configurable styling, let users pick background colors, text colors, fonts.

490
00:24:36.240 --> 00:24:40.319
<v Speaker 2>The book even suggests item categorization with adaptive icons, kind

491
00:24:40.359 --> 00:24:42.400
<v Speaker 2>of like the split wise app does for expenses.

492
00:24:42.640 --> 00:24:44.839
<v Speaker 1>Cool ideas. What about the Pomodora timer.

493
00:24:44.720 --> 00:24:47.279
<v Speaker 2>For the Pomodora application, you could make the working and

494
00:24:47.359 --> 00:24:51.759
<v Speaker 2>resting periods fully configurable by the user, implement longer breaks

495
00:24:51.799 --> 00:24:54.839
<v Speaker 2>after say every four pomodoros.

496
00:24:54.359 --> 00:24:55.839
<v Speaker 1>Standard Pomodora technique rule.

497
00:24:55.960 --> 00:25:00.039
<v Speaker 2>Right, you could display and store user statistics, which but

498
00:25:00.240 --> 00:25:03.759
<v Speaker 2>also need that authentication piece. Maybe let users choose their

499
00:25:03.839 --> 00:25:07.200
<v Speaker 2>preferred noise type from that custom plug. And we talked about.

500
00:25:07.000 --> 00:25:09.720
<v Speaker 1>White, pink or brown noise on demand exactly.

501
00:25:09.759 --> 00:25:12.400
<v Speaker 2>I mean, the possibilities they're really endless once you.

502
00:25:12.359 --> 00:25:14.359
<v Speaker 1>Have the foundation, absolutely, and you don't have to stop

503
00:25:14.359 --> 00:25:15.440
<v Speaker 1>at web apps either, right.

504
00:25:15.599 --> 00:25:19.920
<v Speaker 2>Not at all? Consider extending them. Use tools like weeks

505
00:25:19.960 --> 00:25:22.160
<v Speaker 2>as we mentioned, to try and bring them to mobile,

506
00:25:22.839 --> 00:25:25.599
<v Speaker 2>or maybe turn them into Google Chrome apps, which the

507
00:25:25.599 --> 00:25:27.119
<v Speaker 2>book also touches on briefly.

508
00:25:27.400 --> 00:25:29.319
<v Speaker 1>So take these concepts cross platform.

509
00:25:29.400 --> 00:25:32.519
<v Speaker 2>Why not. You're now equipped. You have all the instruments

510
00:25:32.559 --> 00:25:36.160
<v Speaker 2>you need to enhance these apps, improve them, build new ones,

511
00:25:36.200 --> 00:25:37.960
<v Speaker 2>and show them to the whole world.

512
00:25:38.160 --> 00:25:40.720
<v Speaker 1>A fantastic challenge and a great place to leave it.

513
00:25:41.039 --> 00:25:43.480
<v Speaker 1>You've got the tools, now go build something amazing.