1
00:00:01,080 --> 00:00:04,839
Speaker 1: How'd you like to listen to dot NetRocks with no ads? Easy?

2
00:00:05,360 --> 00:00:08,560
Become a patron for just five dollars a month. You

3
00:00:08,599 --> 00:00:11,320
get access to a private RSS feed where all the

4
00:00:11,359 --> 00:00:14,599
shows have no ads. Twenty dollars a month, we'll get

5
00:00:14,599 --> 00:00:17,679
you that and a special dot net Rocks patron mug.

6
00:00:18,160 --> 00:00:34,840
Sign up now at Patreon dot dot NetRocks dot com. Hey,

7
00:00:34,880 --> 00:00:37,479
welcome back to dot NetRocks. This is Carl Franklin and

8
00:00:37,600 --> 00:00:40,000
this Ridrid Gammon. This is going to be a great show, Richard.

9
00:00:40,479 --> 00:00:41,920
Speaker 2: I'm expecting nothing less.

10
00:00:42,039 --> 00:00:44,920
Speaker 1: Yeah, Dan Roth is here and it's also show nineteen

11
00:00:45,000 --> 00:00:49,960
hundred and twenty two, and I'm summarizing what happened that

12
00:00:50,039 --> 00:00:52,119
year from the peoplehistory dot com.

13
00:00:52,200 --> 00:00:52,520
Speaker 2: Okay.

14
00:00:52,640 --> 00:00:55,799
Speaker 1: In nineteen twenty two, significant global events shape the world.

15
00:00:56,200 --> 00:01:00,000
The Union of the Soviet Socialist republics USSR was formed,

16
00:01:00,399 --> 00:01:03,960
solidifying the rise of communism in the UK. The British

17
00:01:04,000 --> 00:01:08,040
Broadcasting Company or the BBC was founded, making the start

18
00:01:08,120 --> 00:01:13,359
of public radio broadcasting. In science, the first successful insulin

19
00:01:13,439 --> 00:01:16,799
treatment for diabetes took place in Canada. Of course, Canada,

20
00:01:16,840 --> 00:01:20,040
of course, it was meanwhile and refused to patent. It

21
00:01:20,079 --> 00:01:22,560
actually published the specification so that anybody could make it.

22
00:01:22,640 --> 00:01:25,200
Speaker 2: Because you guys are polite, well and you know you

23
00:01:25,319 --> 00:01:26,920
do the right thing. And we don't want to we

24
00:01:26,959 --> 00:01:30,000
don't want to make people alive. Cost a lot of money.

25
00:01:30,000 --> 00:01:30,680
Speaker 1: Who would do that?

26
00:01:30,840 --> 00:01:31,799
Speaker 2: Now? I don't know. I don't know.

27
00:01:33,760 --> 00:01:36,799
Speaker 1: I just make it mad by saying things like that. Meanwhile,

28
00:01:36,840 --> 00:01:41,159
the discovery of King Tut's tomb tooked uncommon, captivated the

29
00:01:41,159 --> 00:01:45,480
world and in Italy Benito Mussolini ros to power. The

30
00:01:45,519 --> 00:01:48,760
Lincoln Memorial was also dedicated in Washington, d C. Commencing

31
00:01:48,840 --> 00:01:53,159
President Abraham's Lincoln legacy. Yeah, and that's only something that

32
00:01:53,200 --> 00:01:54,519
you probably have things to add.

33
00:01:54,719 --> 00:01:54,879
Speaker 3: Oh.

34
00:01:54,879 --> 00:01:57,680
Speaker 2: No, my favorites of that year would be toot In

35
00:01:57,719 --> 00:02:01,519
Commons tomb and the insulin. What else? What can I

36
00:02:01,560 --> 00:02:01,879
think of?

37
00:02:02,120 --> 00:02:02,280
Speaker 4: Uh?

38
00:02:03,480 --> 00:02:05,560
Speaker 2: Egypt becomes independent from Britain.

39
00:02:05,719 --> 00:02:08,520
Speaker 1: Yeah, okay, just was that before or after King Tut's

40
00:02:08,560 --> 00:02:11,680
tomb was well, it was discovered, because wasn't it an

41
00:02:11,719 --> 00:02:13,360
Englishman that discovered? Yeah?

42
00:02:13,400 --> 00:02:15,520
Speaker 2: Howard was an Englishman, no question, do you remember it was?

43
00:02:15,639 --> 00:02:18,599
It was a pleasant handover. It was a civilized han,

44
00:02:18,759 --> 00:02:21,080
right and it's not like the British army actually pulled

45
00:02:21,080 --> 00:02:23,400
out they you know, it's more of the like can

46
00:02:23,439 --> 00:02:25,319
It was sort of like they filled in the form

47
00:02:25,800 --> 00:02:28,159
and made the deal. Wasn't a big revolution or anything.

48
00:02:28,319 --> 00:02:30,960
Speaker 1: Yeah, have a have some champagne. Okay, it's all yours now.

49
00:02:31,080 --> 00:02:33,759
Speaker 2: See well, I mean it still turn into bigger issues

50
00:02:33,759 --> 00:02:35,960
thirty years from now with the Suez Canal crisis. But

51
00:02:36,120 --> 00:02:38,560
you know we'll figure it out that. You know, you've

52
00:02:38,560 --> 00:02:39,960
got a year and a half before we have or

53
00:02:40,039 --> 00:02:41,400
a half a year before I have to talk about

54
00:02:41,439 --> 00:02:46,599
that part thirty episodes from now.

55
00:02:46,680 --> 00:02:49,560
Speaker 1: Yeah, I like this. I like this trajectory we're on here. Okay,

56
00:02:49,599 --> 00:02:53,240
it's very informative. Okay, let's roll the crazy music for

57
00:02:53,319 --> 00:02:54,520
better no a framework?

58
00:03:02,400 --> 00:03:03,400
Speaker 2: All right, man? What do you got?

59
00:03:03,719 --> 00:03:06,240
Speaker 1: Well? I know that you know, Microsoft is all ai

60
00:03:06,280 --> 00:03:12,919
ish these days. It's word definitely ai ish. So I

61
00:03:12,960 --> 00:03:15,840
saw this and I don't know really anything about it.

62
00:03:15,919 --> 00:03:20,759
But this was posted on dev Express's blog on September eighteenth.

63
00:03:21,319 --> 00:03:26,680
New dev Express AI powered blazer Chat component Early access preview.

64
00:03:27,639 --> 00:03:30,199
So it's a new UI library design to incorporate AI

65
00:03:30,319 --> 00:03:34,439
driven interactions into your next great app and deliver responsive,

66
00:03:34,479 --> 00:03:39,639
copilot inspired interfaces with absolute ease. Again, have it checked

67
00:03:39,639 --> 00:03:41,520
it out? I just saw that. It came across my

68
00:03:41,599 --> 00:03:43,599
desk and I was like, you know what, that might

69
00:03:43,639 --> 00:03:45,560
be a good jumping off point for today.

70
00:03:45,960 --> 00:03:48,520
Speaker 2: I also think it's the way we're going to see

71
00:03:48,560 --> 00:03:51,280
a lot of these large language model technologies applied is

72
00:03:51,319 --> 00:03:53,520
as a ux extension to an application.

73
00:03:53,960 --> 00:03:55,400
Speaker 1: Mm hmm. Absolutely.

74
00:03:55,639 --> 00:03:58,280
Speaker 2: And it's not not really a product, it's a feature

75
00:03:58,439 --> 00:03:59,560
to a product. Yeah.

76
00:03:59,759 --> 00:04:02,639
Speaker 1: And and it also makes you rethink your whole UI

77
00:04:02,680 --> 00:04:04,879
in general. If you can do a lot of stuff

78
00:04:04,919 --> 00:04:07,520
with a textbox, why do we need all these other controls.

79
00:04:07,960 --> 00:04:10,000
I'm sure Dan's got ideas about that too.

80
00:04:10,080 --> 00:04:13,439
Speaker 4: So all the smart components coming coming to the ecosystem,

81
00:04:13,479 --> 00:04:15,879
it's it's pretty pretty fun. We've done some of our

82
00:04:15,919 --> 00:04:18,160
own experiments around that in the in Dwton.

83
00:04:18,279 --> 00:04:20,199
Speaker 2: I know it does imply that all everything we've done

84
00:04:20,240 --> 00:04:21,639
up till now was dumb components.

85
00:04:21,920 --> 00:04:26,040
Speaker 4: No, nope, more more intelligent components, don't.

86
00:04:26,040 --> 00:04:26,519
Speaker 2: There you go?

87
00:04:26,600 --> 00:04:28,160
Speaker 1: Yeah, smarter components. I like that.

88
00:04:28,279 --> 00:04:29,480
Speaker 2: Smarter, smarter components.

89
00:04:29,480 --> 00:04:31,879
Speaker 1: There you going. And when we get to smartest components

90
00:04:31,920 --> 00:04:35,879
and then we're done, we can't go any smarter, more

91
00:04:36,040 --> 00:04:40,199
resource intensive components. How about that? Okayeah, that's good. So

92
00:04:40,240 --> 00:04:42,360
that's what I got today. Richard, who's talking.

93
00:04:42,079 --> 00:04:44,600
Speaker 2: To us, grabbed a comment off the show eighteen thirty eight,

94
00:04:44,639 --> 00:04:49,199
the one done by Javier Nelson and Steve Sanderson talking

95
00:04:49,199 --> 00:04:51,800
about Blazer United. One of the few Blazer shows you've

96
00:04:51,800 --> 00:04:54,800
ever done without mister Roth involved directly. Yeah, though I'm

97
00:04:54,800 --> 00:04:56,279
sure he was pretty by the way. This is from

98
00:04:56,279 --> 00:04:59,120
March of twenty twenty three, and lots of good comments

99
00:04:59,120 --> 00:05:02,560
on this show from from our friends, including Richard Ruhima,

100
00:05:02,639 --> 00:05:06,000
who although otherwise known as codeputer yep. On there he says,

101
00:05:06,079 --> 00:05:08,720
this is going to get really interesting. I find this

102
00:05:08,759 --> 00:05:11,040
to be a paradigm shift, not in terms of the web,

103
00:05:11,240 --> 00:05:13,639
but in terms of building an application for the web.

104
00:05:13,680 --> 00:05:16,680
Talking about Blazer United right in this context, not AI

105
00:05:17,079 --> 00:05:20,639
Blazer United, where server and client could be intermixed very easily.

106
00:05:21,199 --> 00:05:25,040
This unity of Blazer styles, I think, simply relates to

107
00:05:25,079 --> 00:05:28,279
where the code resides, which updates the DOM Blazer server.

108
00:05:28,399 --> 00:05:30,439
The DOM is updated on the server and the resulting

109
00:05:30,480 --> 00:05:33,240
dip gram of the UX assent to the browser. Web

110
00:05:33,240 --> 00:05:36,199
assembly is the traditional approach for server pouring the entire

111
00:05:36,240 --> 00:05:39,160
application of the browser just to use client side reasers

112
00:05:39,160 --> 00:05:42,360
to update the DOM to unify and the various design

113
00:05:42,439 --> 00:05:45,240
thoughts expressed here, I thought I could simplify to say

114
00:05:45,279 --> 00:05:48,560
what updates the dom? For example, if I'm using a

115
00:05:48,600 --> 00:05:51,480
click event, why can't I attribute that code as server

116
00:05:51,759 --> 00:05:53,920
and not attribute the code and have it execute on

117
00:05:53,959 --> 00:05:57,079
the client. This is the most granular, but you could

118
00:05:57,079 --> 00:05:59,480
also do it as a component level as well. All data, however,

119
00:05:59,480 --> 00:06:02,600
should be streamed in my opinion, but as that data

120
00:06:02,639 --> 00:06:05,319
becomes available and is simply defined by where it was requested,

121
00:06:05,680 --> 00:06:07,759
I suggested the podcast, I'm going to head over to

122
00:06:07,759 --> 00:06:10,439
GitHub and start planning to participate in what I think

123
00:06:10,639 --> 00:06:13,319
is a very important development in the concept of web

124
00:06:13,360 --> 00:06:14,199
application development.

125
00:06:14,279 --> 00:06:16,240
Speaker 1: Richard is a very thoughtful guy. He was one of

126
00:06:16,279 --> 00:06:20,560
the guys last year at Codena Castle event and just

127
00:06:20,639 --> 00:06:23,079
loved it, and I really enjoyed talking to him well.

128
00:06:23,120 --> 00:06:25,600
Speaker 2: And I don't disagree with this core sentiment here that

129
00:06:25,639 --> 00:06:28,120
we're getting into this idea of units of compute in

130
00:06:28,160 --> 00:06:30,519
the web that could run in multiple places. As a

131
00:06:30,519 --> 00:06:33,000
certainly a conversation we've had mister Standerson before. We're not

132
00:06:33,120 --> 00:06:36,360
just the client or the browser, but some interim location

133
00:06:36,839 --> 00:06:39,959
close to the client but not actually on their machine. Right,

134
00:06:40,399 --> 00:06:48,360
think about us smarter distributed network. Here your local caches

135
00:06:48,399 --> 00:06:51,000
that could actually run compute units for you, so that

136
00:06:51,040 --> 00:06:53,439
they have nice fast interaction with the browser, but the

137
00:06:53,639 --> 00:06:56,439
sensitive data never actually enters a browser unless necessary, and

138
00:06:56,439 --> 00:06:58,480
then trips back to the server asynchronously.

139
00:06:59,319 --> 00:07:02,759
Speaker 1: The the problem I see with that, and basically we're

140
00:07:02,759 --> 00:07:06,839
talking about, is having some button click events that work

141
00:07:06,879 --> 00:07:08,720
on the server and some that work on the client.

142
00:07:08,759 --> 00:07:11,079
And the problem is that if if you're doing server

143
00:07:11,199 --> 00:07:15,360
side Blazer, let's say, uh, it has to keep track

144
00:07:15,399 --> 00:07:18,360
of everything in all the time. Yeah.

145
00:07:18,439 --> 00:07:22,319
Speaker 2: Yeah, Well but imagine you know you want you want

146
00:07:22,319 --> 00:07:24,680
that security of the server side, but you can't handle

147
00:07:24,720 --> 00:07:27,120
the round trip. It takes too long. So you have

148
00:07:27,279 --> 00:07:29,839
you're able to deploy chunks of code to a CDN

149
00:07:30,040 --> 00:07:33,279
close to that browser and have that code execute there

150
00:07:33,839 --> 00:07:34,920
and very low latency.

151
00:07:35,079 --> 00:07:37,040
Speaker 1: Right, But if it changes the dumb and you're still

152
00:07:37,120 --> 00:07:41,120
using a service side dom graph model, that service side

153
00:07:41,160 --> 00:07:43,600
dumb graph model has to stay informed and updated.

154
00:07:43,680 --> 00:07:46,240
Speaker 2: Yeah, so it's got to work both directions. But I

155
00:07:46,279 --> 00:07:49,879
dig it, I think it just gives us options, more

156
00:07:49,959 --> 00:07:53,439
options on where to run our compute. Because you know,

157
00:07:53,759 --> 00:07:55,399
there's a weird way to think about this, which is

158
00:07:55,399 --> 00:07:58,879
a web assembly is almost another kind of container. Oh

159
00:07:58,959 --> 00:08:02,480
definitely right that it's a smaller unit of code that

160
00:08:02,480 --> 00:08:04,680
can be shipped around and executed on demand where you

161
00:08:04,680 --> 00:08:07,680
need it. Richard, thank you so much for your comment.

162
00:08:07,720 --> 00:08:09,680
You always bring up some great ideas, make us think

163
00:08:09,680 --> 00:08:11,560
a little bit. I'd send you a copy of music Cobey,

164
00:08:11,639 --> 00:08:14,120
but I'm pretty sure you got one already. But if

165
00:08:14,160 --> 00:08:16,040
you don't, you know my number, give me a go

166
00:08:16,240 --> 00:08:16,879
I'll look you up.

167
00:08:17,079 --> 00:08:19,000
Speaker 1: Or does anything else? You want a mug or whatever,

168
00:08:19,240 --> 00:08:19,800
just let us know.

169
00:08:19,920 --> 00:08:23,319
Speaker 2: Yeah, whatever you want, brother, you know you're welcome. And

170
00:08:23,360 --> 00:08:24,959
if you'd like copy of music code By, write a

171
00:08:25,000 --> 00:08:27,000
comment on the website of donn at Rocks dot com

172
00:08:27,079 --> 00:08:28,920
or on the facebooks we publish every show there. If

173
00:08:28,959 --> 00:08:30,759
you comment there and ever ready in the show, we'll

174
00:08:30,800 --> 00:08:32,039
send you a copy of music go by.

175
00:08:32,240 --> 00:08:36,120
Speaker 1: And you can always follow Richard Campbell and myself on

176
00:08:36,279 --> 00:08:39,320
ex Twitter. That's we've been there for a long time.

177
00:08:39,799 --> 00:08:42,039
But all the cool kids nowadays are hanging out at

178
00:08:42,039 --> 00:08:45,759
Macedon at least I think so. I'm at Carl Franklin

179
00:08:45,879 --> 00:08:47,840
at tech Hub dot social.

180
00:08:48,159 --> 00:08:50,279
Speaker 2: And I'm rich Campbell at Macedon dot social.

181
00:08:50,440 --> 00:08:52,279
Speaker 1: Send us a toot. It's another way you can get

182
00:08:52,320 --> 00:08:54,720
a free copy of music to code by if we

183
00:08:54,759 --> 00:08:57,000
read your toot. Are they called toots?

184
00:08:57,120 --> 00:08:57,960
Speaker 2: I think they're toots.

185
00:08:58,039 --> 00:08:58,759
Speaker 1: Yeah, I think they are.

186
00:08:59,000 --> 00:09:00,480
Speaker 2: I've been doing a lot of stuff on louse Ky

187
00:09:00,559 --> 00:09:04,240
lately too, and if there's anything that Elon's done, he's

188
00:09:04,279 --> 00:09:07,600
definitely fragmented this market. Yeah.

189
00:09:07,799 --> 00:09:10,919
Speaker 1: I've got a lot more followers on Macedon than I

190
00:09:10,960 --> 00:09:13,000
do on Blue Sky. Blue Sky didn't seem to get

191
00:09:13,039 --> 00:09:15,399
anywhere with me, but I'm still there. Yeah, all right,

192
00:09:15,720 --> 00:09:19,159
so let's bring back mister Daniel Roth. He is a

193
00:09:19,200 --> 00:09:22,960
principal program manager on the aspnet team at Microsoft, specifically

194
00:09:23,000 --> 00:09:28,960
working on dot net web development with Blazer. What's up, Dan, Hi, Carl, Hi, Richard.

195
00:09:28,960 --> 00:09:30,039
Speaker 4: It's great to be here.

196
00:09:29,960 --> 00:09:31,639
Speaker 2: Great to have you, Good to have you back. Friend.

197
00:09:31,799 --> 00:09:34,480
Speaker 1: I guess there's a new dot net in town coming

198
00:09:34,480 --> 00:09:37,399
in November, dot net nine imminently.

199
00:09:38,279 --> 00:09:42,200
Speaker 4: Yeah, just around the corner. Every November release, whether you

200
00:09:42,320 --> 00:09:45,919
want it or not, here comes. Oh you'll want it,

201
00:09:46,000 --> 00:09:49,080
You'll want it nine.

202
00:09:49,159 --> 00:09:49,960
Speaker 2: Yeah. Yeah.

203
00:09:50,120 --> 00:09:52,559
Speaker 1: So I've been reading the blog posts and I saw

204
00:09:52,559 --> 00:09:55,639
the blog post about what's new and asp neet core

205
00:09:55,879 --> 00:09:58,159
for dot net nine, and that included a thing on

206
00:09:58,240 --> 00:10:01,840
Blazer and I'm very lighted to see that in Blazer Server.

207
00:10:02,679 --> 00:10:12,000
I'm calling it the semi opaque veil of death that

208
00:10:12,480 --> 00:10:15,960
happens when you need to reload and you know, the

209
00:10:15,960 --> 00:10:18,960
connection gets broken and stuff, and that is you're really

210
00:10:19,000 --> 00:10:22,960
addressing that with this with this release.

211
00:10:22,879 --> 00:10:26,399
Speaker 4: Release, we're helping. We're helped. I think there's still probably

212
00:10:26,480 --> 00:10:28,840
some more things that we can do to improve that experience,

213
00:10:28,879 --> 00:10:33,279
but yeah, we're making some improvements to the reconnection experience

214
00:10:33,360 --> 00:10:36,799
for apps that use the Blazer server model, or as

215
00:10:36,799 --> 00:10:40,120
we would call it now, the interactive server rendering render mode.

216
00:10:41,120 --> 00:10:43,399
With Blazer server apps, it's a stateful model, right like

217
00:10:43,440 --> 00:10:46,080
you have a live connection with the browser or with

218
00:10:46,120 --> 00:10:49,000
the app to function, and you have server state, and

219
00:10:49,039 --> 00:10:51,919
if the connection gets lost, then the app has this

220
00:10:51,960 --> 00:10:55,120
sort of white overlay that that happens to let the

221
00:10:55,200 --> 00:10:57,440
user know like, hey, I'm the app is not going

222
00:10:57,519 --> 00:10:59,039
to be able to function right now because it doesn't

223
00:10:59,039 --> 00:11:01,720
have that connection. All the uy gets driven from the

224
00:11:01,720 --> 00:11:05,000
server in this in this paradigm, and.

225
00:11:04,960 --> 00:11:07,480
Speaker 1: I find that users just aren't smart enough to configure

226
00:11:07,519 --> 00:11:11,000
that reconnection stuff. They just don't they don't really don't.

227
00:11:10,799 --> 00:11:12,759
Speaker 4: Know on the developer side, yeah, that there are things

228
00:11:12,759 --> 00:11:15,960
you can do, but it it is a bit manual.

229
00:11:15,960 --> 00:11:18,039
In dot AT eight and dot and nine, the goals

230
00:11:18,080 --> 00:11:20,720
to try and make the default set up a little

231
00:11:20,720 --> 00:11:23,159
bit more end user friendly for the people that are

232
00:11:23,279 --> 00:11:25,399
using that that WebApp from that developer.

233
00:11:25,679 --> 00:11:26,960
Speaker 1: Yeah, that's great news.

234
00:11:27,080 --> 00:11:31,080
Speaker 4: Well, well, things that we'll do now will automatically refresh

235
00:11:31,120 --> 00:11:33,799
the browser for the user with when the connection gets

236
00:11:33,799 --> 00:11:37,159
re established and if the app detects like oh, the

237
00:11:37,240 --> 00:11:40,879
user's circuit like their service side state has gone away

238
00:11:40,919 --> 00:11:42,960
for whatever reason like that. That can happen for a

239
00:11:43,039 --> 00:11:46,879
number of different cases, like maybe there was a server

240
00:11:46,919 --> 00:11:49,840
deployment that happened because the servers or restart and whatever

241
00:11:50,080 --> 00:11:53,200
state was held in memory got lost, or maybe the

242
00:11:53,320 --> 00:11:55,559
connection was lost for too long and the server timed

243
00:11:55,559 --> 00:11:57,519
out the circuit and so it just freed up that

244
00:11:57,600 --> 00:12:01,840
those those resources forever. Reason, if the user state got lost,

245
00:12:02,440 --> 00:12:04,159
they kind of need to start again, and before we

246
00:12:04,200 --> 00:12:06,080
would and help them help them with that. And now

247
00:12:06,120 --> 00:12:10,320
in DOTTA nine we will automatically refreshed the browser, the UI,

248
00:12:10,440 --> 00:12:12,720
the UX that you see that the user sees when

249
00:12:12,759 --> 00:12:15,039
that connection gets lost as a little friendlier it's not

250
00:12:15,120 --> 00:12:17,559
that white overlay anymore. It's a little like sort of

251
00:12:17,559 --> 00:12:20,240
mold dialogue style UI. You can you can customize it,

252
00:12:20,279 --> 00:12:22,960
of course, however you'd like. But the fault experience is

253
00:12:23,000 --> 00:12:25,039
a little a little cleaner, and it's a little bit

254
00:12:25,039 --> 00:12:28,600
more responsive, like when the server comes back up, the

255
00:12:28,679 --> 00:12:31,320
user has to wait less time, Like the polling intervals

256
00:12:31,320 --> 00:12:33,960
are a little bit more intelligent in dotted nine, so

257
00:12:33,960 --> 00:12:37,840
they get the app working working faster. So that's that's

258
00:12:37,840 --> 00:12:41,279
all goodness. To be clear, though, the state on the

259
00:12:41,320 --> 00:12:45,480
server is still the responsibility of the app developer. Like

260
00:12:45,919 --> 00:12:47,639
it by the fault is just held in memory. If

261
00:12:47,639 --> 00:12:50,559
you want to that state to survive, you know, sing

262
00:12:50,679 --> 00:12:52,840
things like a server restart or the cirt of going

263
00:12:52,879 --> 00:12:55,200
away and coming back, you do need to still write

264
00:12:55,240 --> 00:12:58,879
code in your application to persist state and rehydrated again

265
00:12:59,000 --> 00:13:01,679
when a user comes back and wants to resume whatever

266
00:13:01,720 --> 00:13:04,120
it was that they were doing. So that that problem

267
00:13:04,200 --> 00:13:08,000
is still very much an application developer problem. In ten

268
00:13:08,159 --> 00:13:11,480
or some future Donnet, we still hope to create patterns

269
00:13:11,519 --> 00:13:14,080
in the framework that make that a little easier. That's

270
00:13:14,120 --> 00:13:16,399
something we in and I hopefully we'll get in the

271
00:13:16,399 --> 00:13:17,200
future I.

272
00:13:17,159 --> 00:13:19,960
Speaker 1: Have a pattern for that actually, and I'll post a

273
00:13:20,000 --> 00:13:22,600
link to it. It's on a GitHub repo. And what

274
00:13:22,679 --> 00:13:26,000
it does is it you create an interface off of

275
00:13:26,039 --> 00:13:30,120
your app state, cascading parameter or cascading value that you

276
00:13:30,200 --> 00:13:33,919
want to persist, and then every time that gets anytime

277
00:13:34,039 --> 00:13:38,919
any of those variables get touched or changed, it persists

278
00:13:38,960 --> 00:13:41,360
those And so you can take that whole idea of

279
00:13:41,399 --> 00:13:44,039
using protected browser storage, or you could save in SQL

280
00:13:44,080 --> 00:13:47,960
server whatever you know, but you save it. You can

281
00:13:48,039 --> 00:13:50,559
even save the page that you were on right, the

282
00:13:51,279 --> 00:13:53,519
form you were filling out, and the fields that you've

283
00:13:53,639 --> 00:13:55,759
entered in the fields that you haven't entered, Like, you

284
00:13:55,799 --> 00:13:57,600
can get down to that kind of level.

285
00:13:57,840 --> 00:14:00,440
Speaker 2: Yeah, which, by the way, delights people. Right, Is there

286
00:14:00,600 --> 00:14:02,440
not better than going back to a page you didn't

287
00:14:02,440 --> 00:14:04,480
finish and the work you've already done is still there.

288
00:14:04,840 --> 00:14:07,360
Speaker 1: Oh yeah, it's terrible if that doesn't happen.

289
00:14:07,600 --> 00:14:10,720
Speaker 2: Well, I think it's expected if it doesn't happen, which

290
00:14:10,720 --> 00:14:13,600
is why it delights when it does. Like, there's not

291
00:14:14,279 --> 00:14:16,720
the tremendously difficult things we have to do, they're not

292
00:14:16,840 --> 00:14:18,960
make people's lives a little bit better and to have

293
00:14:19,039 --> 00:14:21,080
them smile at our software instead of frown.

294
00:14:21,399 --> 00:14:23,720
Speaker 1: I had it. I remember this experience and you guys

295
00:14:23,720 --> 00:14:26,320
probably have two. When I was I was applying for

296
00:14:26,360 --> 00:14:29,440
a loan online and I got you know, there was

297
00:14:29,559 --> 00:14:31,960
like nine pages that I had to fill out, and

298
00:14:31,960 --> 00:14:34,639
I got to page seven and it said, oh, by

299
00:14:34,679 --> 00:14:37,919
the way, which one of these dollar values was the

300
00:14:37,960 --> 00:14:42,399
payment of your mortgage, you know, two years ago or whatever?

301
00:14:42,480 --> 00:14:44,879
And I'm like, what now I have to go. I

302
00:14:45,000 --> 00:14:47,360
have to walk away from the computer, go to the

303
00:14:47,399 --> 00:14:49,639
file camp. By the time I came back, it said

304
00:14:49,360 --> 00:14:51,639
to your sessions timed out. You got to start all

305
00:14:51,639 --> 00:14:56,159
over again. I'm going to someone else now.

306
00:14:56,519 --> 00:14:59,960
Speaker 2: Yeah, yeah, yeah, yeah, this stuff doesn't have to suck.

307
00:15:00,039 --> 00:15:02,360
And I appreciate you built app server thinking in terms

308
00:15:02,399 --> 00:15:04,200
of this is just a component you could add in

309
00:15:04,879 --> 00:15:08,200
and have that behavior happen. Yeah, that's a good idea.

310
00:15:08,919 --> 00:15:11,440
Speaker 1: So what else you got, Dan so well?

311
00:15:11,600 --> 00:15:14,960
Speaker 4: Dotted eight obviously was the big move for Blazer to

312
00:15:15,080 --> 00:15:18,480
become a full stack web framework, like you guys were

313
00:15:18,519 --> 00:15:22,240
mentioning earlier, the Blazer United effort. That was the early

314
00:15:22,320 --> 00:15:25,440
code name that we used for a name name of

315
00:15:25,480 --> 00:15:28,759
that technology of uniting all the Blazers into one thing.

316
00:15:28,840 --> 00:15:29,840
Where you now it's just.

317
00:15:29,840 --> 00:15:33,519
Speaker 5: Called Blazer, the Blazer web app as well the way,

318
00:15:34,720 --> 00:15:38,120
but you can have different render modes that you turn

319
00:15:38,200 --> 00:15:41,000
on or off inside your Blazer web app to light

320
00:15:41,039 --> 00:15:43,240
up different functionality in different places.

321
00:15:43,840 --> 00:15:49,759
Speaker 4: And so that model really unified the web development experience

322
00:15:49,799 --> 00:15:51,679
for for dot Net, like whether you're doing server or

323
00:15:51,679 --> 00:15:54,559
doing client, you can do it with just one component

324
00:15:54,600 --> 00:15:58,000
model using Blazer components, and it really positioned Blazers our

325
00:15:58,399 --> 00:16:00,960
you know, our our primary our rec commended solution for

326
00:16:01,000 --> 00:16:04,480
building web UI starting with with dot neet eight. But

327
00:16:04,720 --> 00:16:07,639
it was new, like there's certainly user experience gaps in

328
00:16:07,679 --> 00:16:10,639
that in that in that model that we're still ironing

329
00:16:10,639 --> 00:16:14,159
out and filling in. The reconnection experience was was one

330
00:16:14,159 --> 00:16:16,960
thing we did. Another is giving you more run time

331
00:16:17,039 --> 00:16:22,200
visibility into which render mode is currently active. Like just

332
00:16:22,320 --> 00:16:26,000
as a to walk you through a very common Blazer flow.

333
00:16:26,159 --> 00:16:28,840
You might make the initial request to a Blazer web

334
00:16:28,840 --> 00:16:33,279
app and it will render HTML from the server statically,

335
00:16:33,320 --> 00:16:35,480
like just give you some HTMIL immediately. We often call

336
00:16:35,559 --> 00:16:39,000
that pre rendering. That's a form of just static server

337
00:16:39,080 --> 00:16:41,320
side rendering where you get HTMIL down to the browser

338
00:16:41,360 --> 00:16:43,200
as fast as you can so you get pixels on

339
00:16:43,200 --> 00:16:44,679
the user's screen as quickly as you.

340
00:16:44,720 --> 00:16:47,200
Speaker 2: Get stuff floating look at.

341
00:16:47,600 --> 00:16:49,919
Speaker 4: Then you might have interactive features though on that page

342
00:16:49,960 --> 00:16:52,000
that you want to enable, like you want to handle

343
00:16:52,039 --> 00:16:54,840
those button clicks or drag and drop or whatever, and

344
00:16:54,879 --> 00:16:56,720
you have a choice on whether you do that from

345
00:16:56,759 --> 00:16:59,679
the server using interactive server rendering or from the client

346
00:16:59,759 --> 00:17:03,840
using web assembly based rendering. Now, while you're waiting for

347
00:17:04,039 --> 00:17:08,400
that interactivity to light up, there might be interactive features

348
00:17:08,440 --> 00:17:10,720
on the page that aren't quite functional yet, like the

349
00:17:10,720 --> 00:17:12,640
counter button if you try to click on it in

350
00:17:12,640 --> 00:17:16,960
that split second before interactivity has been enabled. There's nothing

351
00:17:17,039 --> 00:17:20,559
yet set up for to handle those UI events or

352
00:17:20,640 --> 00:17:23,440
due to do dynamic UI updates. So what you can

353
00:17:23,480 --> 00:17:25,640
do now in Dota nine, we give you a runtime

354
00:17:25,640 --> 00:17:29,519
API for detecting the render mode. So when you do

355
00:17:29,640 --> 00:17:33,359
that first static service side render, you might maybe disable

356
00:17:33,640 --> 00:17:36,319
the interactive features or don't render them yet, like wait

357
00:17:36,400 --> 00:17:39,359
until interactivity is now live, right, and then when the

358
00:17:39,359 --> 00:17:43,160
component renders interactively, like through from the over the web

359
00:17:43,200 --> 00:17:45,880
socket connection or on web assembly, you then light up

360
00:17:45,880 --> 00:17:48,720
those interactive features so they're now available for the user

361
00:17:48,839 --> 00:17:49,480
to use.

362
00:17:49,519 --> 00:17:50,599
Speaker 2: So you have this.

363
00:17:50,640 --> 00:17:54,440
Speaker 4: Capability now of structuring the dom, adjusting the component rendering

364
00:17:54,759 --> 00:17:57,480
based on how that component is currently being rendered, which

365
00:17:57,519 --> 00:17:58,720
render mode is currently act.

366
00:17:58,680 --> 00:18:01,799
Speaker 1: Nice and saving and low state is kind of important, right,

367
00:18:01,839 --> 00:18:04,640
because if you go from an interactive thing where you've

368
00:18:04,640 --> 00:18:08,799
got some state to a non interactive thing where you don't,

369
00:18:09,480 --> 00:18:12,480
and then back to an interactive thing, what happens to

370
00:18:12,519 --> 00:18:13,319
your state? Right?

371
00:18:13,400 --> 00:18:15,160
Speaker 4: You might you know, yeah, you need some some way

372
00:18:15,200 --> 00:18:17,599
of flowing that around, and that can be that can

373
00:18:17,720 --> 00:18:21,119
be tricky, you know, you mentioned earlier options like I

374
00:18:21,119 --> 00:18:23,480
think I think this is sort of one of the

375
00:18:23,480 --> 00:18:26,240
the industry trends right now in front in web development

376
00:18:26,319 --> 00:18:29,720
that the frameworks are getting are getting very powerful in

377
00:18:29,799 --> 00:18:33,799
terms of the the flexibility and how you render your components,

378
00:18:33,839 --> 00:18:35,359
Like you can render your components from the server, you

379
00:18:35,359 --> 00:18:37,839
can render them from the from the client, and various

380
00:18:38,680 --> 00:18:42,839
mixed cases as well, like enhanced uh static, enhanced navigation

381
00:18:42,920 --> 00:18:46,160
and forum handling, streaming rendering. These these new patterns that

382
00:18:46,319 --> 00:18:48,640
enable you to make your app more feel, more responsive,

383
00:18:49,079 --> 00:18:52,119
load faster, have a better user experience, but it does

384
00:18:52,160 --> 00:18:56,400
also result in complexity, like and it can result in

385
00:18:56,400 --> 00:18:59,799
like these types of architectural questions that you're asking about like, well,

386
00:18:59,799 --> 00:19:02,400
how I now flow state from each of these different

387
00:19:02,440 --> 00:19:04,599
types of rendering within my application.

388
00:19:04,839 --> 00:19:05,119
Speaker 1: Yeah.

389
00:19:05,440 --> 00:19:07,640
Speaker 4: I think that's something that you know in general, not

390
00:19:07,680 --> 00:19:10,440
just in Blazer, but like whether you're doing React or Angular,

391
00:19:10,880 --> 00:19:14,200
you know, React server components, our thing right next JS

392
00:19:13,960 --> 00:19:17,839
has similar patterns or newer frameworks like Astro and solid

393
00:19:18,319 --> 00:19:21,960
like figuring out ways to help users navigate the complexity

394
00:19:22,000 --> 00:19:25,119
of these different ways of rendering. Web UI is I

395
00:19:25,119 --> 00:19:27,400
think an ongoing, an ongoing, challenging problem.

396
00:19:27,440 --> 00:19:27,839
Speaker 2: Yeah.

397
00:19:27,920 --> 00:19:31,200
Speaker 1: Yeah, just to be clear, you can use some props.

398
00:19:31,279 --> 00:19:35,519
So when dot Net eight came out, Rocky Laca and

399
00:19:35,559 --> 00:19:40,960
I noticed that there was some problems with scope services

400
00:19:41,000 --> 00:19:43,039
just sort of dying and going null on you when

401
00:19:43,039 --> 00:19:46,240
you switched modes. And that seems to have been fixed.

402
00:19:46,599 --> 00:19:48,519
I didn't see a lot of fanfare about it, but

403
00:19:48,960 --> 00:19:51,920
I tried it recently for a talk I was giving

404
00:19:52,079 --> 00:19:56,079
and lo and behold those scope services are now surviving

405
00:19:56,759 --> 00:20:00,279
the in it. Yeah, which is great, which is great.

406
00:20:00,519 --> 00:20:03,799
So I mean working is expected, there was Yeah, working

407
00:20:03,920 --> 00:20:06,119
is expected, but you know, there's like he said, there

408
00:20:06,160 --> 00:20:07,640
were some glitches with dot and it eate when it

409
00:20:07,680 --> 00:20:09,759
came out, and some of those things are being correct

410
00:20:09,799 --> 00:20:13,319
and hats off man. Good stuff. Laser goes on.

411
00:20:13,440 --> 00:20:15,400
Speaker 4: Laser continues to do to improve we do. We do

412
00:20:15,480 --> 00:20:17,480
try to listen to to user feedback. I think they're

413
00:20:17,480 --> 00:20:20,960
still like with state and persistence, like we were talking

414
00:20:20,960 --> 00:20:24,440
about you know, your own libraries to helping with service

415
00:20:24,480 --> 00:20:26,960
side persistence. I still think there's more to be to

416
00:20:27,000 --> 00:20:29,559
be done, Like we've wanted for a while to have

417
00:20:29,599 --> 00:20:32,559
like a more declarative model for persistence in Blazer where

418
00:20:32,640 --> 00:20:34,759
you can sort of declare on your component, like here's

419
00:20:34,759 --> 00:20:37,480
stuff that I'd like to be that's awesome persisted or

420
00:20:37,519 --> 00:20:40,400
survive the pre render to the interactive rendering flow and

421
00:20:40,759 --> 00:20:43,160
all these places where you want to flow state around

422
00:20:43,559 --> 00:20:47,880
helping with framework patterns UH to deal with those types

423
00:20:47,920 --> 00:20:49,680
of types of issues, and those are things I think

424
00:20:49,680 --> 00:20:51,839
we'll look at in a future version.

425
00:20:51,960 --> 00:20:55,720
Speaker 2: It's cool, very cool. The relationship with MAUI. I mean

426
00:20:55,759 --> 00:20:58,720
they'd come up later than you know, Blazer's been around

427
00:20:58,799 --> 00:21:02,039
longer and there's sort of this energy around this is

428
00:21:02,079 --> 00:21:05,720
your you know, all purpose client environment. What are you

429
00:21:05,720 --> 00:21:06,240
guys doing.

430
00:21:06,440 --> 00:21:10,119
Speaker 4: We have a great partnership and integration with with MAUI.

431
00:21:10,319 --> 00:21:14,000
I mean MAUI is all about cross platform native client

432
00:21:14,039 --> 00:21:17,039
apps like you want to use, and Mali really specializes

433
00:21:17,079 --> 00:21:20,119
in enabling you to use the native view y controls

434
00:21:20,119 --> 00:21:22,839
and elements from the underlying platform. You when you render

435
00:21:22,839 --> 00:21:26,680
a button, yeah, and you're gonna get the iOS button.

436
00:21:26,680 --> 00:21:28,839
When you are on an Android, you get the Android button,

437
00:21:28,920 --> 00:21:30,960
or when y you get the winduw I button. That's

438
00:21:31,000 --> 00:21:33,640
their their bread and butter. Where we plug into Mali

439
00:21:33,680 --> 00:21:38,119
with Blazer is well, you can render a WebView control

440
00:21:38,160 --> 00:21:40,759
within a Maui app on regardless of the platform you're on,

441
00:21:41,200 --> 00:21:43,440
and from that WebView control, you can then render Blazer

442
00:21:43,440 --> 00:21:45,559
components from from the device. So this is what we

443
00:21:45,640 --> 00:21:49,160
call the Blazer hybrid pattern. And actually, Donta nine we

444
00:21:49,440 --> 00:21:53,200
have a new solution template I guess we could call

445
00:21:53,240 --> 00:21:56,920
it for doing both a dott Maui Blazer hybrid app

446
00:21:57,319 --> 00:22:00,200
in conjunction with a Blazer web app where you want

447
00:22:00,200 --> 00:22:02,559
to target not only the native client platforms with your

448
00:22:02,920 --> 00:22:07,000
Blazer components, but also the webs web, mobile and desktop

449
00:22:07,359 --> 00:22:10,920
with one template setup. That's something you could do in

450
00:22:10,920 --> 00:22:12,240
Donna Dight, but you had to kind of set it

451
00:22:12,279 --> 00:22:14,200
up manually. It was a bit bit tedious and Dota

452
00:22:14,279 --> 00:22:15,359
nine we give you a pre kit.

453
00:22:15,640 --> 00:22:17,880
Speaker 2: It is a bit inception, ye, right, that you have

454
00:22:18,039 --> 00:22:21,359
an UX inside of a framework inside of a UX

455
00:22:21,480 --> 00:22:24,119
A little bit, yeah.

456
00:22:23,480 --> 00:22:27,039
Speaker 4: But it's very common. Like we use these style of

457
00:22:27,079 --> 00:22:29,640
apps all the time. If anyone's using Visual Studio code

458
00:22:30,039 --> 00:22:33,039
have a native shell with a you know, chromium based

459
00:22:33,319 --> 00:22:38,240
web view sitting inside of it. Your editor Microsoft teams

460
00:22:38,039 --> 00:22:41,720
is built with a similar technology stack of similar similar

461
00:22:41,799 --> 00:22:45,680
architecture or hybrid style architecture. Sure, the Blazer hybrid pattern

462
00:22:45,720 --> 00:22:48,480
just lets you do it with Blazer components as opposed

463
00:22:48,519 --> 00:22:50,680
to having to do it with JavaScript, right.

464
00:22:50,759 --> 00:22:53,000
Speaker 1: I also like the fact that you can mix a match,

465
00:22:53,200 --> 00:22:56,160
Like you can build a WPF app that has a

466
00:22:56,160 --> 00:22:59,440
Blazer view for your main content and then hey, if

467
00:22:59,440 --> 00:23:02,440
you can't find a good Blazer calendar control, you can

468
00:23:02,559 --> 00:23:05,640
use a WPF calendar control and pop that up right,

469
00:23:05,720 --> 00:23:08,920
and you know what I mean, it's just wind forms

470
00:23:08,960 --> 00:23:12,640
or vice versa. Yeah, So you can truly use the

471
00:23:13,200 --> 00:23:16,640
platforms inside the different platforms inside of an app for

472
00:23:17,480 --> 00:23:20,599
what you know, the best of breed technology is whatever.

473
00:23:20,759 --> 00:23:23,160
Speaker 4: I was talking with some of the Maui folks, and

474
00:23:23,200 --> 00:23:25,400
I think in some cases they like if if there's

475
00:23:25,440 --> 00:23:30,000
a control that's not quite available or not quite working

476
00:23:30,000 --> 00:23:32,480
the way people want. At the native layer. People often

477
00:23:32,519 --> 00:23:34,680
will go the Blazer hybrid rout to go grab a

478
00:23:34,720 --> 00:23:37,720
control from you know, popular web frameworks or Blazer that

479
00:23:37,920 --> 00:23:39,880
use that inside their mauway up and that that works

480
00:23:39,960 --> 00:23:41,319
very quite quite quite well for them.

481
00:23:41,400 --> 00:23:45,440
Speaker 2: Yeah, I just wonder about performance behavior, Like there's all

482
00:23:45,440 --> 00:23:48,680
the subtleties that work when you're pulling in components through

483
00:23:48,680 --> 00:23:52,279
these different layers like that, like does this UX hold together?

484
00:23:52,359 --> 00:23:55,119
Does it look like this is a different component stat

485
00:23:55,119 --> 00:23:57,240
that came from a different Blazer. Does it look like

486
00:23:57,279 --> 00:23:58,119
it's all unified?

487
00:23:58,240 --> 00:24:01,039
Speaker 4: Yeah? That that's so. The thing you lose out with

488
00:24:01,079 --> 00:24:04,640
the Blazer hybrid pattern is you are now rendering web

489
00:24:04,720 --> 00:24:06,960
UI within the native shell. If you've stuck with just

490
00:24:07,039 --> 00:24:10,680
native native controls like the MAUI abstractions. For those native controls,

491
00:24:11,000 --> 00:24:14,880
you get the look and feel consistency of that platform,

492
00:24:14,960 --> 00:24:17,079
Like it'll look like an iOS app when it's running

493
00:24:17,079 --> 00:24:18,839
on iOS, it will look like an Android app when

494
00:24:18,839 --> 00:24:21,680
it's on Android. Once you go into the hybrid world

495
00:24:21,799 --> 00:24:22,519
you're now in that.

496
00:24:22,599 --> 00:24:23,559
Speaker 2: It looks like a web app.

497
00:24:23,960 --> 00:24:26,359
Speaker 4: Yeah, well, however you style that that web app you

498
00:24:26,359 --> 00:24:28,119
want it to look IOSC. Then you're gonna have to

499
00:24:28,200 --> 00:24:31,160
use some CSS styles that make it follow the iOS

500
00:24:31,920 --> 00:24:32,720
design patterns.

501
00:24:32,799 --> 00:24:35,240
Speaker 2: Or if you want all your textbox to be in flames, yes,

502
00:24:35,279 --> 00:24:36,359
CSS will do that for you.

503
00:24:36,440 --> 00:24:37,519
Speaker 4: Yes, you can do it.

504
00:24:38,480 --> 00:24:40,440
Speaker 1: All your text box are belonging to S.

505
00:24:40,559 --> 00:24:43,319
Speaker 2: Yes. No applying for taste here, that's not it.

506
00:24:44,000 --> 00:24:46,000
Speaker 4: I want you want to mention like for performance. I

507
00:24:46,039 --> 00:24:48,680
actually think that the Blazer hybrid pattern is is a

508
00:24:48,720 --> 00:24:52,720
really good story for a performance because the rendering of

509
00:24:52,759 --> 00:24:56,839
the Blazer components is happening natively on the device. Like

510
00:24:56,880 --> 00:25:00,799
there's no web assembly involved. No, there's no website get involved.

511
00:25:01,039 --> 00:25:04,640
You're running your dot net Blazer components on a normal

512
00:25:04,880 --> 00:25:07,759
dot net run time with JIT and normal garbage collector

513
00:25:07,799 --> 00:25:10,680
and all that stuff running on the device. It's then

514
00:25:10,799 --> 00:25:14,000
just talking to the WebView control over like a local

515
00:25:14,000 --> 00:25:17,880
interrupt channel. So the component rendering is quick. That's very performant.

516
00:25:18,200 --> 00:25:20,519
You do have a little extra weight because you are

517
00:25:20,599 --> 00:25:22,440
bringing the web platform with.

518
00:25:22,480 --> 00:25:24,880
Speaker 2: You as soon as the web control comes into play.

519
00:25:25,000 --> 00:25:29,160
That's a spicy meatball, right, yeah, and spicy meat.

520
00:25:29,160 --> 00:25:31,000
Speaker 1: And you can look, you know, you can look at

521
00:25:31,039 --> 00:25:34,039
the task manager and see the difference right. The native

522
00:25:35,400 --> 00:25:39,119
Maui stuff is smaller, right, and then you have the

523
00:25:39,279 --> 00:25:42,960
in the in the process for the for the Blazer Hybrid,

524
00:25:43,000 --> 00:25:46,200
you've got you know, edge webe chromium, the WebView and

525
00:25:46,279 --> 00:25:50,119
all of the stuff that comes with it. Right. So yeah, yeah,

526
00:25:50,160 --> 00:25:51,480
you aren't going to use more memory.

527
00:25:51,640 --> 00:25:53,920
Speaker 2: You're going to feel it now that last time I look,

528
00:25:54,000 --> 00:25:56,279
most of these machines have way too much memory anyway.

529
00:25:56,359 --> 00:26:00,000
Speaker 1: So I totally agree Richard. Never run out of memory

530
00:26:00,200 --> 00:26:02,920
on my iPhone to take back.

531
00:26:02,759 --> 00:26:04,880
Speaker 4: The memory so they don't have so much to waste.

532
00:26:06,279 --> 00:26:08,240
Speaker 1: I had. I had a group in here in the

533
00:26:08,279 --> 00:26:11,799
studio the other night when we're recording something, and he says,

534
00:26:11,920 --> 00:26:15,119
you know, he's trying to punch in and and I said, dude,

535
00:26:15,359 --> 00:26:16,880
I'm not going to run out of tape.

536
00:26:17,039 --> 00:26:17,799
Speaker 2: It's gonna be okay.

537
00:26:17,839 --> 00:26:20,880
Speaker 1: You know, you can go as many times as long

538
00:26:20,920 --> 00:26:23,799
as you want. You can just keep recording. He's like, oh, stop,

539
00:26:23,880 --> 00:26:26,440
go back, you know. No, no, not gonna run out

540
00:26:26,440 --> 00:26:27,920
of tape, not going to run out of memory.

541
00:26:28,440 --> 00:26:30,559
Speaker 2: I'm not going to stop. It's not going to just

542
00:26:30,640 --> 00:26:34,119
have one continuous stream, keep going. It's like my phone's

543
00:26:34,119 --> 00:26:36,559
not running out of film. It's going to be take

544
00:26:36,559 --> 00:26:37,200
another picture.

545
00:26:37,200 --> 00:26:42,079
Speaker 1: It's okay, right, Yeah, yeah, this is just leftover behaviors

546
00:26:42,119 --> 00:26:43,319
from old technologies.

547
00:26:43,359 --> 00:26:46,079
Speaker 2: Yeah, I mean there is a phones have some constraints

548
00:26:46,079 --> 00:26:50,160
they but mostly bandwidth related ones and storage related ones

549
00:26:50,160 --> 00:26:53,559
depending on what phone you're getting. But yeah, definitely we

550
00:26:53,640 --> 00:26:56,880
have you know, maintainability is more important these days and

551
00:26:57,039 --> 00:26:58,240
optimizing the bites.

552
00:26:58,480 --> 00:27:00,839
Speaker 1: Still, when my phone starts running low on battery, the

553
00:27:00,880 --> 00:27:03,440
first thing I do is close all the apps that

554
00:27:03,680 --> 00:27:04,640
are running there.

555
00:27:04,680 --> 00:27:07,440
Speaker 2: You go, well, I just swapped up my phone because

556
00:27:07,440 --> 00:27:09,880
the last one started to grow in the way that

557
00:27:09,960 --> 00:27:11,759
says this will catch fire soon.

558
00:27:12,400 --> 00:27:14,160
Speaker 1: So you mean like capacitors.

559
00:27:14,319 --> 00:27:19,440
Speaker 2: No, the battery started to expand popular expanding Yeah, yike.

560
00:27:19,960 --> 00:27:22,480
Not a good sign. No, not at all. So I

561
00:27:22,559 --> 00:27:24,559
moved on. Hey, we should take a little break, and

562
00:27:24,599 --> 00:27:24,880
then I.

563
00:27:24,839 --> 00:27:26,680
Speaker 1: Get some questions. All right, we'll be right back after

564
00:27:26,720 --> 00:27:30,480
these messages. Did you know you can lift and shift

565
00:27:30,559 --> 00:27:34,200
your dot net framework apps to virtual machines in the cloud.

566
00:27:35,000 --> 00:27:39,200
Use the elastic beanstalk service to easily migrate to Amazon

567
00:27:39,279 --> 00:27:43,400
EC two with little or no changes. Find out more

568
00:27:43,440 --> 00:27:53,160
at aws dot Amazon dot com slash elastic beanstalk. And

569
00:27:53,240 --> 00:27:55,160
we're back. It's dot in a Rocks and Carl Franklin,

570
00:27:55,200 --> 00:27:57,920
my friend Richard Campbell, Heye, and our friend Daniel Roth

571
00:27:57,920 --> 00:27:59,960
from Microsoft in just as a reminder, if you don't

572
00:28:00,079 --> 00:28:02,599
want to hear these ads, because let's face it, some

573
00:28:02,680 --> 00:28:05,319
of them you really don't want to hear, you can

574
00:28:05,559 --> 00:28:08,160
for five dollars a month go to Patreon dot dot

575
00:28:08,200 --> 00:28:11,440
nerocks dot com and become a patron and you'll get

576
00:28:11,440 --> 00:28:12,759
a feed that's ad free.

577
00:28:13,039 --> 00:28:13,480
Speaker 2: Nice.

578
00:28:13,680 --> 00:28:16,759
Speaker 1: All right, where were we dan? What's on your list next?

579
00:28:16,839 --> 00:28:17,759
Speaker 2: What have we covered? So?

580
00:28:18,279 --> 00:28:20,319
Speaker 4: I think it's important to stress that for DOTT nine,

581
00:28:20,720 --> 00:28:22,720
a lot of what we're doing in this release is

582
00:28:22,759 --> 00:28:27,160
about quality and fundamentals, like the features always get the

583
00:28:27,480 --> 00:28:32,000
headlines right, new new capabilities, new functionality. But a pretty

584
00:28:32,000 --> 00:28:34,599
significant investment was made in DOTTA nine just to focus

585
00:28:34,640 --> 00:28:40,440
on things like performance, security, accessibility, just making sure that

586
00:28:40,519 --> 00:28:44,319
the fundamentals of what we're shipping our top top quality.

587
00:28:44,640 --> 00:28:47,319
I'm sure many people listening have heard of the Secure

588
00:28:47,680 --> 00:28:51,480
Future initiative from microclock. The whole dot net team has

589
00:28:51,519 --> 00:28:54,000
been participating in that effort as well, making sure that

590
00:28:54,079 --> 00:28:58,079
every feature we ship is secure by default, has secure

591
00:28:58,119 --> 00:29:00,799
characteristics for our users, and that's all.

592
00:29:00,680 --> 00:29:04,240
Speaker 2: Work, expects to expects to managed identity, like those kinds

593
00:29:04,279 --> 00:29:07,000
of things, right, really doing the zero testing.

594
00:29:07,279 --> 00:29:10,960
Speaker 4: Making sure our samples show you best practices for the

595
00:29:11,079 --> 00:29:15,200
latest threats and how you mitigate them, and just making

596
00:29:15,200 --> 00:29:17,799
sure that our own infrastructure, of course is is as

597
00:29:17,880 --> 00:29:20,640
tight and as secure as it possibly can be, a

598
00:29:20,680 --> 00:29:24,359
lot of works gone to security performance, though it is

599
00:29:24,359 --> 00:29:26,920
always a big area of investment.

600
00:29:27,319 --> 00:29:29,200
Speaker 2: There is Steven tow isn't there.

601
00:29:29,680 --> 00:29:33,759
Speaker 4: Has published his tomb Yes, the tome.

602
00:29:36,839 --> 00:29:38,559
Speaker 2: Taking I know what I'm doing this weekend.

603
00:29:39,720 --> 00:29:41,759
Speaker 4: I gotta say, like these these perform I know he

604
00:29:41,799 --> 00:29:44,400
does a lot of like micro benchmarking part of showing

605
00:29:44,400 --> 00:29:48,440
those benefits, but these benefits are real. Like we Donnet

606
00:29:48,559 --> 00:29:52,759
is used heavily internally at Microsoft by our largest products,

607
00:29:53,039 --> 00:29:57,480
you know Microsoft teams being in Tune, Xbox, like these

608
00:29:57,599 --> 00:30:00,440
huge properties are using don net to power their back

609
00:30:00,559 --> 00:30:04,440
ends and they just love that. Every donnet version comes out,

610
00:30:04,480 --> 00:30:06,119
they install that on to.

611
00:30:06,240 --> 00:30:09,319
Speaker 2: Change nothing and things are faster. Actually, some of my

612
00:30:09,440 --> 00:30:13,839
favorite blog posts have been like the team's team saying,

613
00:30:14,039 --> 00:30:17,400
here's our benchmarks. When we were on seven, and then

614
00:30:17,480 --> 00:30:20,400
we switch to eight, here's the things we needed to fix,

615
00:30:20,599 --> 00:30:22,400
and then we ran the same benchmarks again and here's

616
00:30:22,440 --> 00:30:26,240
our performance on eight. Like those, I think are very

617
00:30:26,279 --> 00:30:30,400
compelling for folks to see Microsoft consumes its own dog food,

618
00:30:30,440 --> 00:30:32,920
like this is a product they use and they are

619
00:30:32,920 --> 00:30:36,680
getting these benefits too, and they care about them. Absolutely, Yeah, absolutely.

620
00:30:36,759 --> 00:30:41,680
I would tie that back to the Secure Future initiative

621
00:30:42,200 --> 00:30:45,599
in the sense that it is still too hard to

622
00:30:45,680 --> 00:30:48,960
write really secure code, but I'm glad you guys are

623
00:30:49,000 --> 00:30:52,279
doing it because it will then get easier because you

624
00:30:52,359 --> 00:30:55,799
need You've got deadlines too, right, and as soon as

625
00:30:55,839 --> 00:30:57,880
security gets in the way enough that you're serious and

626
00:30:57,920 --> 00:31:00,440
considering circumventing it, like you know where those guys work,

627
00:31:00,559 --> 00:31:02,880
go get them and make it better.

628
00:31:03,880 --> 00:31:05,200
Speaker 4: Fix it.

629
00:31:05,680 --> 00:31:09,000
Speaker 2: Well, I remember what happened to WPF when the studio

630
00:31:09,039 --> 00:31:11,640
team started implementing it back for the twenty ten edition.

631
00:31:12,440 --> 00:31:16,279
WPF took this massive leap in improvement because those guys

632
00:31:16,799 --> 00:31:19,440
rang it out and found its weaknesses and then hunted

633
00:31:19,519 --> 00:31:21,680
down the folks who built it and made it better.

634
00:31:21,799 --> 00:31:24,279
Speaker 1: And the dot Net Framework the same thing happened when

635
00:31:24,319 --> 00:31:27,039
it was embedded in SQL service. Yeah, shook it out,

636
00:31:27,079 --> 00:31:28,240
They beat the snot out of it.

637
00:31:28,640 --> 00:31:33,359
Speaker 4: Things get used, they get refined in the the world.

638
00:31:33,480 --> 00:31:36,039
Speaker 2: Yeah, but it's also there's there's a little insider angle

639
00:31:36,079 --> 00:31:40,079
there where one Microsoft team's being impeded by another Microsoft team.

640
00:31:40,240 --> 00:31:43,680
Like that gets energy right that you can actually make

641
00:31:43,680 --> 00:31:45,480
step better. That will all bet of fit from. Like

642
00:31:45,559 --> 00:31:49,359
I expect our process of making secure dot net applications

643
00:31:49,400 --> 00:31:51,119
to get dramatically better the next year.

644
00:31:51,200 --> 00:31:53,839
Speaker 4: It is a goal that as we improve our own security,

645
00:31:53,839 --> 00:31:56,799
that that spreads to the rest of the eCos rolls

646
00:31:56,839 --> 00:31:59,160
out to everybody. One example I can think of is

647
00:31:59,519 --> 00:32:02,119
like one technique we're using internally on our code basis

648
00:32:02,200 --> 00:32:05,400
is you know, static code analysis scanning, scanning our codebases

649
00:32:05,480 --> 00:32:08,440
looking for problems in an automated fashion. One of the

650
00:32:08,480 --> 00:32:10,559
tools we use for that is code ql, which is

651
00:32:10,599 --> 00:32:14,200
a publicly available suite that's used as part of our

652
00:32:14,319 --> 00:32:18,200
get up Advanced Security offering for scanning codebases. And so

653
00:32:18,279 --> 00:32:21,039
as we you know, tweak and refine the rules that

654
00:32:21,079 --> 00:32:23,240
we use for scanning our code bases, then those can

655
00:32:23,240 --> 00:32:25,880
become available to external users and that that whole story

656
00:32:25,960 --> 00:32:29,559
just gets better and stronger, so you can find issues

657
00:32:29,839 --> 00:32:33,480
faster in an automated way. So security top top priority.

658
00:32:34,240 --> 00:32:36,359
You know, huge amount of resources being spent on making

659
00:32:36,359 --> 00:32:39,400
sure that our uh that that that our users can

660
00:32:39,440 --> 00:32:42,480
trust the products that we ship from Microsoft because everything

661
00:32:42,480 --> 00:32:43,920
else rides on top of.

662
00:32:43,880 --> 00:32:46,880
Speaker 1: That getting back performance from it, and just this will

663
00:32:46,920 --> 00:32:49,599
give you a good segway for you. Uh. I recall

664
00:32:49,799 --> 00:32:52,240
several years ago. I don't remember what which version of

665
00:32:52,279 --> 00:32:54,079
dot net it was, but it was like, for the

666
00:32:54,119 --> 00:33:00,599
first time dot Net was outperforming. It's uh, you know,

667
00:33:00,720 --> 00:33:04,039
not its rivals or its adversaries, but it's competitors. It's

668
00:33:04,079 --> 00:33:08,079
competitive stacks in terms of you know, speed and performance.

669
00:33:08,680 --> 00:33:11,680
And you know, at that point I was like, ah, okay,

670
00:33:11,839 --> 00:33:14,319
dot Net is the most performance. I don't have to

671
00:33:14,319 --> 00:33:16,440
worry about that now. But then you know, of course

672
00:33:16,519 --> 00:33:21,759
every year those competitors' platforms also increase their performance. And

673
00:33:21,799 --> 00:33:24,240
you've got this cat and mouse team, So what is

674
00:33:24,279 --> 00:33:27,119
it in terms of performance? Do you know what the

675
00:33:27,200 --> 00:33:31,240
rank is in terms of compared to everything else.

676
00:33:31,400 --> 00:33:33,920
Speaker 4: The benchmark that we use for that and that we

677
00:33:33,960 --> 00:33:37,000
target and Donnett is the Tech and Power Benchmarks, which

678
00:33:37,000 --> 00:33:39,960
are a public set of benchmarks that look at all

679
00:33:40,039 --> 00:33:43,680
the developer ecosystems that are on the planet. They implement

680
00:33:43,720 --> 00:33:46,279
the same suite of benchmark tests and then they run

681
00:33:46,319 --> 00:33:49,440
them and you can go and look and compare how

682
00:33:49,799 --> 00:33:53,720
different implementations of different stacks look against each other. And

683
00:33:54,119 --> 00:33:55,920
I don't have the numbers off the top of my head,

684
00:33:55,960 --> 00:33:57,839
but you can, of course just go and check the

685
00:33:57,880 --> 00:33:59,680
tech power benchmarks yourself.

686
00:34:00,079 --> 00:34:01,599
Speaker 1: And we were Richard's doing that area.

687
00:34:01,640 --> 00:34:07,119
Speaker 4: Well, yep, very very well on those benchmarks.

688
00:34:07,160 --> 00:34:09,519
Speaker 2: You guys are always in the top few, right, I

689
00:34:09,519 --> 00:34:10,599
mean the the.

690
00:34:11,000 --> 00:34:14,119
Speaker 4: And usually it's the top few where we're like often

691
00:34:14,159 --> 00:34:16,239
the one that is like the thing you would actually

692
00:34:16,599 --> 00:34:18,280
consider using, like some of the other there are some.

693
00:34:18,440 --> 00:34:20,360
Speaker 2: Right, yeah, some of these stacks are pretty weird.

694
00:34:21,039 --> 00:34:24,760
Speaker 4: Academic I would say there are some other good stacks

695
00:34:24,760 --> 00:34:26,440
out there. I don't want to say there are.

696
00:34:26,480 --> 00:34:29,159
Speaker 2: Sure, yeah, there's plenty. There's plenty of good stacks. But

697
00:34:29,239 --> 00:34:33,480
there dot net Core sitting at twenty three out of

698
00:34:33,599 --> 00:34:37,000
what two hundred, three hundred, five hundred.

699
00:34:36,920 --> 00:34:39,679
Speaker 4: Say pretty confidently that if you choose dot net for

700
00:34:39,719 --> 00:34:42,519
your service stack, you will be very happy with its performance.

701
00:34:42,599 --> 00:34:45,519
Speaker 2: Character performance will not be an issue. That's it's not

702
00:34:45,559 --> 00:34:46,840
going to be an issue.

703
00:34:47,039 --> 00:34:49,480
Speaker 4: And that's proven out in the real world by like

704
00:34:49,519 --> 00:34:51,760
we were talking earlier about us running down it in our

705
00:34:51,760 --> 00:34:54,519
own data centers, for our own cloud, for our.

706
00:34:54,400 --> 00:34:55,440
Speaker 2: Own product offering.

707
00:34:55,519 --> 00:34:57,519
Speaker 1: Okay, so Dan, I hate to put you on the spot,

708
00:34:57,559 --> 00:35:00,840
but if I ask you this every time I interview you,

709
00:35:01,320 --> 00:35:04,440
back when dot net was just coming out, dot net server,

710
00:35:05,159 --> 00:35:07,920
you showed at dot ne kof a slide where you

711
00:35:07,960 --> 00:35:13,000
did a headless test of the skew that Blazer server

712
00:35:13,159 --> 00:35:15,519
was running on. How much RAM and how many CPUs

713
00:35:16,039 --> 00:35:22,599
versus how many consecutive users you could have, not consecutive concurrent,

714
00:35:23,079 --> 00:35:26,840
how many concurrent users you can have before a click

715
00:35:27,639 --> 00:35:31,519
result doesn't return in two hundred milliseconds, which is kind

716
00:35:31,519 --> 00:35:34,760
of the brain benchmark by which people think it's slow.

717
00:35:35,960 --> 00:35:41,000
And you said that I think it was five thousand

718
00:35:41,440 --> 00:35:44,840
for like, don't know, four gigs of RAM, and if

719
00:35:44,840 --> 00:35:48,880
you increase that to something in for CPUs, it got more.

720
00:35:49,239 --> 00:35:50,920
And the other thing that you said was how much

721
00:35:50,960 --> 00:35:55,159
overhead blazer server used for each user to keep the state,

722
00:35:55,239 --> 00:35:57,360
to keep the dom and back then I think it

723
00:35:57,400 --> 00:36:01,920
was eighty five k. Do you have any idea, I mean,

724
00:36:01,920 --> 00:36:05,599
you probably don't have a number, but would you expect

725
00:36:05,599 --> 00:36:07,719
that number to go up or to go down?

726
00:36:08,119 --> 00:36:10,559
Speaker 4: With the number to go down, give them amount of

727
00:36:10,559 --> 00:36:13,239
performance tuning we've had, but I don't think we've run

728
00:36:13,239 --> 00:36:15,960
that test again since we did. It Initially was done

729
00:36:16,000 --> 00:36:19,119
as sort of a just a proof point to show

730
00:36:19,199 --> 00:36:22,039
that Laser Server wasn't going to be the bottleneck for

731
00:36:23,000 --> 00:36:24,239
a good chunk of apps.

732
00:36:24,920 --> 00:36:25,400
Speaker 2: I think it was.

733
00:36:25,639 --> 00:36:27,519
Speaker 4: It was act like it was a fairly small VM

734
00:36:27,559 --> 00:36:30,159
that you could run five thousand concurrent users and.

735
00:36:30,159 --> 00:36:32,920
Speaker 1: A more yeah, like a gig of RAM or something.

736
00:36:33,039 --> 00:36:35,239
Speaker 4: Yeah, and a more reasonable size VM you could easily

737
00:36:35,280 --> 00:36:38,880
handle twenty thousand concurrent using Blazer Server. Of course, that

738
00:36:38,960 --> 00:36:41,079
changes as you add your own app logic, like if

739
00:36:41,119 --> 00:36:44,159
you start allocating a bunch of memory for each circuit

740
00:36:44,320 --> 00:36:47,719
for each user, then that will yeah, that's baseline change

741
00:36:47,760 --> 00:36:51,320
the dynamics. But as a baseline, Blaser Server can certainly

742
00:36:51,400 --> 00:36:56,400
handle quite easily with fairly reasonable hardware tens of thousands

743
00:36:56,440 --> 00:37:00,599
of current users without sweating. And Microsoft do that all the.

744
00:37:00,599 --> 00:37:04,639
Speaker 1: Time on one server, And this question I get asked

745
00:37:04,679 --> 00:37:07,000
all the time, and just to so that everybody can

746
00:37:07,239 --> 00:37:09,599
not make sure that I didn't lie to them, I'll

747
00:37:09,639 --> 00:37:13,360
ask you. So, if you want to scale out Blazer Server,

748
00:37:13,960 --> 00:37:19,840
you use the signal our service from Azure, and so

749
00:37:19,920 --> 00:37:23,559
then you can scale out add more servers, right, so

750
00:37:23,639 --> 00:37:27,719
if you're twenty thousand concurrent user servers and enough, you

751
00:37:27,719 --> 00:37:31,599
add another one. But by default affinity is on, so

752
00:37:32,280 --> 00:37:34,960
connections are sticky. So when somebody comes in and they

753
00:37:35,159 --> 00:37:37,760
log in and they register, they're always using that server,

754
00:37:38,360 --> 00:37:41,079
so you don't have to worry about, oh, this time

755
00:37:41,119 --> 00:37:43,840
when they press this button, it went to this particular

756
00:37:43,840 --> 00:37:46,800
server which doesn't have my state. So is that that

757
00:37:46,920 --> 00:37:47,360
is true?

758
00:37:47,440 --> 00:37:47,679
Speaker 2: Right?

759
00:37:47,760 --> 00:37:50,079
Speaker 4: That is still the pattern You need to have session

760
00:37:50,119 --> 00:37:52,760
affinity in order to run Blazer server apps because it

761
00:37:52,800 --> 00:37:53,880
is a statefold.

762
00:37:54,119 --> 00:37:57,320
Speaker 1: It's on by default in an app service, I think yes.

763
00:37:58,880 --> 00:38:03,199
Speaker 4: And the signal Our service, what purpose that serves is

764
00:38:03,559 --> 00:38:06,280
helping you with the connections scaled out, Like if you

765
00:38:06,320 --> 00:38:10,119
have a server environment, we're flooding it with you know,

766
00:38:10,159 --> 00:38:13,480
tens of thousands of concurrent web socket connections might be

767
00:38:13,639 --> 00:38:18,159
an issue. They signal ADUs signilar service can help multiplex

768
00:38:18,199 --> 00:38:22,079
those connections so that your server infrastructure is less loaded

769
00:38:22,119 --> 00:38:25,800
on the at the connection part of the application in

770
00:38:25,840 --> 00:38:29,239
many Azure services. Actually, we recently updated our guidance around

771
00:38:29,239 --> 00:38:31,599
the Azure signal Our service, so it's worth noting if

772
00:38:31,599 --> 00:38:35,840
you're using it today. In Azure app service, having lots

773
00:38:35,880 --> 00:38:37,719
and lots of website and connections used to be more

774
00:38:37,760 --> 00:38:40,280
of a concern than it is now, and so for

775
00:38:40,440 --> 00:38:43,599
most of our Azure based hosts, we no longer say

776
00:38:43,639 --> 00:38:45,519
that you need to use the adres signal our service

777
00:38:45,559 --> 00:38:49,079
in companionship with it, because those services can already handle

778
00:38:49,119 --> 00:38:51,719
the number of web socket connections by themselves, so it's

779
00:38:51,719 --> 00:38:54,239
not a normally a problem. But if you have another

780
00:38:54,320 --> 00:38:56,480
environment where that might be an issue, then the address

781
00:38:56,480 --> 00:38:57,960
Signal our service is a great option.

782
00:38:58,159 --> 00:38:59,280
Speaker 1: That's really good news.

783
00:39:00,599 --> 00:39:03,039
Speaker 2: And yeah, you added a bunch of signal R features

784
00:39:03,079 --> 00:39:04,239
for nine right.

785
00:39:04,159 --> 00:39:07,360
Speaker 4: Yeah, yeah. Signal are now has sports polymorphic types, so

786
00:39:07,400 --> 00:39:09,519
if you want to like pass an instance of a

787
00:39:09,559 --> 00:39:12,880
derived type to to your hub methods, you can do that.

788
00:39:13,559 --> 00:39:16,679
There was some work done around its tracing model, like

789
00:39:16,719 --> 00:39:21,000
how how signal handles UH distributed tracing. It used to

790
00:39:21,039 --> 00:39:24,199
be that all the hub invocations would kind of appear

791
00:39:24,280 --> 00:39:26,920
under one big, giant long request, right, because these are

792
00:39:27,000 --> 00:39:30,840
usually long running web socket connections, and so it looks

793
00:39:30,880 --> 00:39:33,679
kind of weird when you're trying to analyze the distributed traces.

794
00:39:34,079 --> 00:39:36,320
They now kind of appear more more like you would

795
00:39:36,320 --> 00:39:40,119
imagine a request reply style trace, uh looking in the

796
00:39:40,800 --> 00:39:43,719
in the traces, which is much It's much nicer when

797
00:39:43,719 --> 00:39:45,599
you're like looking at your signal r hubs in like

798
00:39:45,639 --> 00:39:49,360
the Aspire dashboard, you get a much easier view to

799
00:39:49,519 --> 00:39:52,119
parts to see the what's what's happening with your your hubs.

800
00:39:52,800 --> 00:39:56,360
So those are both new on the there's a couple

801
00:39:56,400 --> 00:39:59,920
of performance improvements. I also wanted to mention on Blazer side,

802
00:40:00,400 --> 00:40:04,119
the for Blazer server or interactive server rendering, we now

803
00:40:04,159 --> 00:40:07,440
do compression at the web socket layer. So the traffic

804
00:40:07,719 --> 00:40:11,079
that gets sent to your Blazer server hub, which itself

805
00:40:11,119 --> 00:40:13,239
is a signaler hub underneath the cover, so it also

806
00:40:13,239 --> 00:40:16,559
benefits from all those signal features too, but that traffic

807
00:40:16,599 --> 00:40:19,719
is smaller and therefore has a lower latency and is faster.

808
00:40:20,719 --> 00:40:22,840
On the web assembly side, we did a bunch of

809
00:40:22,880 --> 00:40:26,719
work on the startup performance of the web assembly runtime.

810
00:40:27,480 --> 00:40:29,960
In the past, we've we've focused a lot on shrinking

811
00:40:29,960 --> 00:40:32,079
the download size so that you can get the bits

812
00:40:32,480 --> 00:40:35,000
for the dotted web assembly runtime onto the device as

813
00:40:35,079 --> 00:40:38,360
quickly as possible, and that is still important, and we

814
00:40:38,119 --> 00:40:42,079
we've shrunk that thing of as far down as as

815
00:40:42,119 --> 00:40:44,320
we can, and we look for ways to improve that,

816
00:40:44,719 --> 00:40:47,960
but there is also still some latency that can occur

817
00:40:48,000 --> 00:40:50,039
when you then boot it up, like you say, okay,

818
00:40:50,119 --> 00:40:53,599
now run the runtime. That can take a you know,

819
00:40:54,599 --> 00:40:57,239
some some number of milliseconds to actually get the runtime started,

820
00:40:57,280 --> 00:41:01,320
which also delays the the interactive state of your app.

821
00:41:01,360 --> 00:41:03,440
So we focused on that and dot at nine and

822
00:41:03,719 --> 00:41:05,400
sped that up by good like I don't remember the

823
00:41:05,440 --> 00:41:09,119
exact number, but something like twenty thirty percent faster runtime

824
00:41:09,159 --> 00:41:13,239
startup performance. And then broadly for asp dot Core, we

825
00:41:13,320 --> 00:41:16,880
did a bunch of work around static web assets, like

826
00:41:16,920 --> 00:41:20,519
the static files that make up your your web applications,

827
00:41:20,559 --> 00:41:23,280
whether this is a Blaser app or an NBC app

828
00:41:23,320 --> 00:41:25,480
or a Razor Pages app, anything that lives in your

829
00:41:25,519 --> 00:41:30,599
dubdub root folder. We now will build and publish time

830
00:41:31,119 --> 00:41:34,119
identify those static web assets and do a bunch of

831
00:41:34,199 --> 00:41:38,320
optimizations on them. We will free the print their filenames

832
00:41:38,400 --> 00:41:42,159
so they have unique caches in the filenames that enables

833
00:41:42,239 --> 00:41:45,679
us to then aggressively cash them when they're being served,

834
00:41:45,719 --> 00:41:47,920
Like we can basically KnowI browsers that cash us forever,

835
00:41:48,000 --> 00:41:49,880
because if there's a new version of it, I'm just

836
00:41:49,920 --> 00:41:51,320
going to change the file name, so you don't need

837
00:41:51,519 --> 00:41:52,360
to worry about that.

838
00:41:52,559 --> 00:41:52,840
Speaker 2: Wow.

839
00:41:53,199 --> 00:41:56,119
Speaker 4: We also pre compress them at build and published time

840
00:41:56,320 --> 00:41:59,440
using Broadley compression. It's very similar to what we've had

841
00:41:59,480 --> 00:42:02,440
in Blazer web assembly for a while, but now it's

842
00:42:02,480 --> 00:42:04,760
done for any static web asset that you have that

843
00:42:05,400 --> 00:42:08,440
isn't already in a compressed format. So thinks CSS files,

844
00:42:08,519 --> 00:42:11,800
jobscript files. The acement core tooling will now do a

845
00:42:12,119 --> 00:42:15,039
precompression on those those those files as well, so your

846
00:42:15,079 --> 00:42:18,719
static web assets load faster and they're better cased, and

847
00:42:18,760 --> 00:42:21,800
that helps Blazer apps as well as any dot Net

848
00:42:22,199 --> 00:42:22,960
web front.

849
00:42:22,760 --> 00:42:25,159
Speaker 1: And lazy loading comes to mind when you said that,

850
00:42:25,320 --> 00:42:28,360
and are you doing any lazy loading automatically in the

851
00:42:28,400 --> 00:42:31,960
background of your own assets in the dot Net framework

852
00:42:32,159 --> 00:42:34,800
or is do we still can we still benefit from

853
00:42:34,840 --> 00:42:36,000
doing that ourselves.

854
00:42:37,159 --> 00:42:40,000
Speaker 4: So there's lazyloading and Blazer where you can like sort

855
00:42:40,000 --> 00:42:41,960
of take a chunk of your app that gets downloaded

856
00:42:42,000 --> 00:42:43,320
to the client and say, you know what, I don't

857
00:42:43,320 --> 00:42:45,920
need this yet. I will tell you when I'm going

858
00:42:45,960 --> 00:42:47,880
to load this, and then they can be lazyloaded in

859
00:42:47,960 --> 00:42:51,960
later that that feature still exists for static web assets.

860
00:42:52,559 --> 00:42:54,760
There are I don't think we've we got to this

861
00:42:54,840 --> 00:42:57,519
point dot at nine, but on our roadmap we also

862
00:42:57,559 --> 00:42:59,519
would like to do like preloading. It's not not really

863
00:42:59,599 --> 00:43:01,960
lazy looad, but like saying like sure, hey, I'm about

864
00:43:02,000 --> 00:43:04,320
to go to this asset and i can see that

865
00:43:04,400 --> 00:43:06,400
it needs these other files too, so go ahead and

866
00:43:06,960 --> 00:43:09,199
preload those into the browser because I'm probably going to

867
00:43:09,280 --> 00:43:12,639
request them them soon. Like having links in your Yeah,

868
00:43:12,679 --> 00:43:15,639
that's that's smart HDMIL. That's signal of that's that will

869
00:43:15,679 --> 00:43:20,320
be the case. That can avoid waterfall style loading of

870
00:43:20,320 --> 00:43:22,920
assets in your webpages that can slow things down. If

871
00:43:22,960 --> 00:43:25,119
you can avoid that waterfall, then things will load faster

872
00:43:25,159 --> 00:43:25,480
as well.

873
00:43:25,639 --> 00:43:26,039
Speaker 2: Very cool.

874
00:43:26,119 --> 00:43:28,719
Speaker 4: That's a future optimization that we hope to get to.

875
00:43:28,960 --> 00:43:31,400
Speaker 2: Nice hate really great. I'm I'm going to go a

876
00:43:31,440 --> 00:43:33,119
little off the beaten path here because I was just

877
00:43:33,159 --> 00:43:36,440
going through some of the notes and it ran across

878
00:43:36,519 --> 00:43:39,880
this mention of multiple Blazer web apps per server project,

879
00:43:39,880 --> 00:43:42,360
which I totally get. I've dug into the issue and

880
00:43:42,400 --> 00:43:44,039
so forth, where it's like, okay, you know you've got

881
00:43:44,079 --> 00:43:46,360
to comment back end several different clients that they want

882
00:43:46,400 --> 00:43:49,400
to manage in one project. What what I smiled at

883
00:43:49,440 --> 00:43:51,480
was when I saw this is tagged for dot net

884
00:43:51,599 --> 00:43:55,719
ten November twenty twenty five, and it's just like, man,

885
00:43:55,800 --> 00:43:58,639
that's organized, Like we know definitely when this is going

886
00:43:58,719 --> 00:44:01,760
to make it for another version, but it just speaks

887
00:44:01,840 --> 00:44:07,280
to the whole conversation about this was a user submitting

888
00:44:07,360 --> 00:44:10,519
the issue? I think just looking at the GitHub reposts

889
00:44:10,599 --> 00:44:14,480
like November of twenty three, so it was it was

890
00:44:14,679 --> 00:44:20,079
right after dot net eight had shipped, is when they

891
00:44:20,400 --> 00:44:22,519
sort of post this issue. I'm sure folks were talking

892
00:44:22,559 --> 00:44:24,039
about it before then, but I'm just looking at this

893
00:44:24,119 --> 00:44:26,559
particular issue, like can you talk a bit about this flow.

894
00:44:26,559 --> 00:44:28,960
I don't imagine this is your problem or not, Dan,

895
00:44:29,079 --> 00:44:30,840
but it's just interesting to me, like.

896
00:44:30,800 --> 00:44:34,320
Speaker 4: How we manage the user feedback and that.

897
00:44:34,719 --> 00:44:37,079
Speaker 2: Yeah, and that's whole triage, Like the fact that it's

898
00:44:37,079 --> 00:44:38,840
all in gidhub now where people can just write an

899
00:44:38,840 --> 00:44:43,039
issue and I see guys like Havia interacting with this

900
00:44:43,119 --> 00:44:46,719
issue and you know, taking it seriously and queuing it up.

901
00:44:46,920 --> 00:44:48,679
Speaker 4: Yeah, yeah, this is this is good to know because

902
00:44:48,679 --> 00:44:51,440
this is how you can understand if you have a

903
00:44:51,440 --> 00:44:53,559
feature that's important to you, how you can engage with

904
00:44:53,639 --> 00:44:57,000
us on the Blazer team to make sure your your

905
00:44:57,440 --> 00:45:00,599
your feedback and your perspectives on these issues is being heard.

906
00:45:00,960 --> 00:45:03,639
So all the feedback everything that we do is publicly

907
00:45:03,679 --> 00:45:06,159
tracked on GitHub. We are a fully public open source

908
00:45:06,280 --> 00:45:08,760
project and that's where we operate. That's where our devs

909
00:45:08,800 --> 00:45:11,199
do their day to day work, and it's part of

910
00:45:11,239 --> 00:45:14,039
every release. And we're about to go into the ten

911
00:45:14,320 --> 00:45:16,800
planning cycle to think through what are we going.

912
00:45:16,760 --> 00:45:19,320
Speaker 2: To do with You're you're in our see now. So

913
00:45:19,360 --> 00:45:23,159
there's clearly stuff that's been triaged out to next and

914
00:45:23,159 --> 00:45:25,159
it's time and this is probably one of them. And

915
00:45:25,199 --> 00:45:27,000
yet now you're starting to sort out like what lives

916
00:45:27,000 --> 00:45:27,440
in next?

917
00:45:27,599 --> 00:45:30,639
Speaker 4: Yeah, so we we we have a number of different

918
00:45:30,679 --> 00:45:33,400
signals that we use to figure out, okay, what what

919
00:45:33,440 --> 00:45:35,320
do we want to push up the stack on our

920
00:45:35,360 --> 00:45:39,320
on our backlog. The one that's most user facing is

921
00:45:39,320 --> 00:45:41,280
if you just go to a GitHub issue and use

922
00:45:41,320 --> 00:45:43,679
the thumbs up reactions right to say like this is

923
00:45:43,719 --> 00:45:45,559
important to me, and do it on the original post,

924
00:45:45,559 --> 00:45:46,239
do it at the top.

925
00:45:46,440 --> 00:45:50,360
Speaker 2: Now I see fourteen fourteen thumbs up on that one.

926
00:45:50,800 --> 00:45:53,480
Speaker 4: Please don't get this, like, please don't look your friends

927
00:45:53,760 --> 00:45:56,360
from a bot network to click thumbs up on these things,

928
00:45:56,400 --> 00:45:57,920
because we do use it as a signal, and we

929
00:45:57,960 --> 00:46:01,199
know it's a rough signal. Yeah, at least lets us know, like, yeah,

930
00:46:01,239 --> 00:46:03,679
I care about this too, so please please consider this.

931
00:46:05,079 --> 00:46:08,880
The next, like level two of helping us out is

932
00:46:08,920 --> 00:46:11,000
if you could post a comment on the GitHub issue

933
00:46:11,000 --> 00:46:14,559
explaining the why, explaining the scenario that you care about

934
00:46:14,559 --> 00:46:16,079
and why this is really important.

935
00:46:16,079 --> 00:46:18,199
Speaker 2: Well, and you have a nice template here the is

936
00:46:18,239 --> 00:46:21,320
there an existing issue? Is it really or fature requests

937
00:46:21,320 --> 00:46:23,679
related to a problem? Can you tell us about the problem,

938
00:46:24,159 --> 00:46:27,320
describe the solution you'd like, you know, some additional context,

939
00:46:27,360 --> 00:46:30,199
Like you've given us some structure to sort of describe

940
00:46:30,280 --> 00:46:30,920
the issue to you.

941
00:46:31,000 --> 00:46:33,199
Speaker 4: So if you're the one that's posting the original issue,

942
00:46:33,199 --> 00:46:35,360
like you're actually the one making the request, then you

943
00:46:35,519 --> 00:46:38,519
follow the template, fill out that information, give us, give

944
00:46:38,599 --> 00:46:41,320
us as much data as you can on your scenario,

945
00:46:41,519 --> 00:46:44,840
your requirements, and why it's important, because that's all stuff

946
00:46:44,840 --> 00:46:47,800
that we read through and factor into our prioritization. Even

947
00:46:47,840 --> 00:46:49,920
if it's an issue that you find is already filed,

948
00:46:50,039 --> 00:46:53,199
it's still helpful for you to post another comment saying

949
00:46:53,239 --> 00:46:55,239
also this is important to me because of X, Y

950
00:46:55,280 --> 00:46:56,880
and Z, So give us more perspective.

951
00:46:57,000 --> 00:47:01,039
Speaker 2: Right, I mean this emphasis on search first, because if

952
00:47:01,079 --> 00:47:03,719
there's an existing issue that you can contribute to, you

953
00:47:03,800 --> 00:47:07,079
increase the likelihood of this happening a weight, right, the

954
00:47:07,079 --> 00:47:10,760
weight gets bigger where multiple separate requests are less powerful

955
00:47:10,800 --> 00:47:13,719
than one big one that everybody's contributing.

956
00:47:13,800 --> 00:47:16,599
Speaker 1: It seems to me that before GitHub, you know, if

957
00:47:16,639 --> 00:47:18,920
you were to, if anyone were to approach a team

958
00:47:18,960 --> 00:47:21,920
member and say, hey, I have this, why don't you

959
00:47:22,000 --> 00:47:24,960
implement this feature? Blah blah blah blah blah, that Microsoft

960
00:47:25,360 --> 00:47:29,639
team members were programmed to say, why would you ever

961
00:47:29,719 --> 00:47:34,119
want to do that? Right? I mean I've gotten that answer,

962
00:47:34,159 --> 00:47:36,800
and I've seen them give that answer to in person,

963
00:47:37,320 --> 00:47:40,719
because that it's not necessarily a combative question, but it

964
00:47:40,719 --> 00:47:44,840
really makes you think I want less compa that I think, no, no,

965
00:47:45,039 --> 00:47:47,440
But I mean it's a great question. But I think

966
00:47:47,559 --> 00:47:49,719
that that's kind of what you're doing with GitHub. You know,

967
00:47:49,840 --> 00:47:53,320
what is the real issue that you're having. Perhaps you've

968
00:47:53,320 --> 00:47:56,920
already gone several abstractions higher than you need to go,

969
00:47:57,559 --> 00:47:59,920
and maybe let's get to the core of the problem.

970
00:48:00,440 --> 00:48:03,079
Speaker 4: And sometimes that's about us. We want to understand the

971
00:48:03,079 --> 00:48:05,960
core of the problem because maybe you're requesting a particular solution,

972
00:48:06,400 --> 00:48:09,519
but if you take the more context on what the

973
00:48:09,559 --> 00:48:11,599
problem actually is, like what you're trying to solve, that

974
00:48:11,679 --> 00:48:13,920
might lead us to a different solution that would work

975
00:48:13,960 --> 00:48:16,880
better from a framework authoring perspective, like maybe we can

976
00:48:16,920 --> 00:48:19,559
broaden the solution that would help not only your scenario

977
00:48:19,559 --> 00:48:22,519
but also these other scenarios and you know, line things better.

978
00:48:22,559 --> 00:48:26,119
So though, the why behind your request is really really helpful.

979
00:48:26,440 --> 00:48:28,639
Speaker 1: And the search thing that Richard was talking about is

980
00:48:28,639 --> 00:48:31,840
important too, because like in my world, I get probably

981
00:48:31,920 --> 00:48:35,719
ten people coming to me a year with ideas for apps.

982
00:48:36,079 --> 00:48:38,119
I have the idea, you build it and will split

983
00:48:38,159 --> 00:48:40,440
it fifty to fifty. I think it's all the time right,

984
00:48:41,039 --> 00:48:43,639
And I always say, all right, before you come back

985
00:48:43,639 --> 00:48:45,400
to me again, I want you to do a thorough

986
00:48:45,440 --> 00:48:47,880
search to see if that app already exists, and I

987
00:48:48,000 --> 00:48:49,480
knit they never come back.

988
00:48:51,280 --> 00:48:53,599
Speaker 4: There's a lot of people with the ideas out there.

989
00:48:53,639 --> 00:48:56,599
It's hard to prome with something truly unique. A couple

990
00:48:56,639 --> 00:48:59,440
of other things though, that are worth noting, So we will.

991
00:48:59,480 --> 00:49:02,719
We have our backlog milestone that's where we put everything

992
00:49:02,760 --> 00:49:04,599
that's like, you know, something we may consider to do

993
00:49:04,599 --> 00:49:08,480
at some point. We often will have a you mentioned

994
00:49:08,519 --> 00:49:12,360
a ten milestone, Richard, and usually that's a doit ten

995
00:49:12,440 --> 00:49:13,480
planning milestone.

996
00:49:13,599 --> 00:49:15,280
Speaker 2: Yeah, and I see it here now as I read

997
00:49:15,320 --> 00:49:16,840
deeper into this thing, it's like you can see you

998
00:49:16,880 --> 00:49:18,800
the point where when okay, this is going to be

999
00:49:18,800 --> 00:49:22,159
in ten like it was initially in nine, and then

1000
00:49:22,199 --> 00:49:23,639
it would know it's going to make it to ten.

1001
00:49:23,880 --> 00:49:26,559
Speaker 4: So Donna ten planning is the stuff that we're like,

1002
00:49:26,880 --> 00:49:29,599
it's kind of like a level above the the just

1003
00:49:29,599 --> 00:49:31,639
being on the backlog. It's stuff that we have already

1004
00:49:31,639 --> 00:49:33,760
thought about that we do think is important, right, and

1005
00:49:33,800 --> 00:49:36,000
we'd like to consider as part of what we're going

1006
00:49:36,039 --> 00:49:38,760
to do in intent. It almost always has more stuff

1007
00:49:38,760 --> 00:49:40,719
in that milestone than we could ever possibly sure.

1008
00:49:40,800 --> 00:49:43,119
Speaker 2: Sure it is like the next it's where you put

1009
00:49:43,119 --> 00:49:45,599
all the next it might split across more so, it's not.

1010
00:49:45,559 --> 00:49:48,599
Speaker 4: A commitment yet, it's a it's a planning tool that

1011
00:49:48,599 --> 00:49:50,079
we used to say, you know, this is probably the

1012
00:49:50,079 --> 00:49:51,639
first batch of stuff that we'll look at for the

1013
00:49:51,760 --> 00:49:54,679
dot tent planning. And then we take all the user

1014
00:49:54,760 --> 00:49:58,239
data that the reactions, we take our our own understanding

1015
00:49:58,239 --> 00:50:00,559
about where's the industry going, Like we go do you know,

1016
00:50:00,639 --> 00:50:03,599
analysis on what other frameworks are doing, what's what's happening

1017
00:50:03,679 --> 00:50:06,000
on the web platform. We look from that direction, and

1018
00:50:06,000 --> 00:50:08,559
then we of course look from our own business priorities

1019
00:50:08,599 --> 00:50:11,559
and from Microsoft pays the bills.

1020
00:50:11,639 --> 00:50:13,920
Speaker 2: Yep, there's things they need. You're going to have to

1021
00:50:13,960 --> 00:50:14,559
do those things.

1022
00:50:14,639 --> 00:50:18,119
Speaker 4: The roadmap, the committed roadmap, and even this commitment is

1023
00:50:18,119 --> 00:50:21,800
is it's it's our our best understanding at the moment.

1024
00:50:21,960 --> 00:50:25,280
Roadmap then usually gets published early, like first quarter of

1025
00:50:25,320 --> 00:50:27,599
the year saying this is what we think we're doing

1026
00:50:27,639 --> 00:50:30,480
an ACEMT Core and Blazer for say dot ten, and

1027
00:50:30,519 --> 00:50:33,079
that should published on GitHub. That is still of course

1028
00:50:33,119 --> 00:50:36,840
subject to change. You know, software development is hard. We

1029
00:50:36,840 --> 00:50:39,320
we often sometimes we misjudge how much things are going

1030
00:50:39,360 --> 00:50:42,800
to cost. Sometimes initiatives come in that change plans, like

1031
00:50:42,800 --> 00:50:45,119
the secure initiative was certainly something.

1032
00:50:44,880 --> 00:50:47,400
Speaker 2: That definitely drew resources off change.

1033
00:50:47,119 --> 00:50:50,400
Speaker 4: Things for dot net nine. So the roadmap I wouldn't

1034
00:50:50,519 --> 00:50:53,679
view even that as like a guaranteed to happen for

1035
00:50:53,760 --> 00:50:56,000
the release. It's one of those things actually that I've

1036
00:50:56,039 --> 00:50:57,960
been we've been trying to improve on. It's like, have

1037
00:50:58,079 --> 00:51:01,119
that roadmap be more more trustworthy that yes, these things

1038
00:51:01,119 --> 00:51:02,760
will actually get done, but it is at least our

1039
00:51:02,760 --> 00:51:05,400
best understanding at that moment about what we think we're

1040
00:51:05,400 --> 00:51:06,280
going to bite off for.

1041
00:51:06,239 --> 00:51:08,840
Speaker 1: The I can also imagine that if you implement a

1042
00:51:08,880 --> 00:51:13,480
feature too soon that it can it can be more

1043
00:51:13,519 --> 00:51:18,079
of a problem later, So deferring a feature for the

1044
00:51:18,119 --> 00:51:21,320
next version the next version after that can often come

1045
00:51:21,400 --> 00:51:23,679
on the heels of an analysis that says, ah, before

1046
00:51:23,679 --> 00:51:26,360
we solve that problem. We have to solve these problems

1047
00:51:26,519 --> 00:51:30,639
because that will make this one a lot more intelligent

1048
00:51:30,840 --> 00:51:33,360
or whatever that we won't have to backfill.

1049
00:51:33,559 --> 00:51:36,239
Speaker 4: It's for people that maybe get frustrated by that, because

1050
00:51:36,239 --> 00:51:37,840
it can be frustrating right where you have like a

1051
00:51:37,880 --> 00:51:40,920
feature that's important that gets delayed from release to release.

1052
00:51:41,519 --> 00:51:45,039
Might I think the one that's maybe close to people's

1053
00:51:45,679 --> 00:51:48,679
minds at this point for web assembly is our multi

1054
00:51:48,679 --> 00:51:51,280
threading support. We've we've had multi threading on our i

1055
00:51:51,280 --> 00:51:54,159
think on our roadmap now for like two or three releases,

1056
00:51:54,360 --> 00:51:56,840
wanting to get it done, and then for various reasons

1057
00:51:56,880 --> 00:52:00,159
it having to be to be pushed out. Things that

1058
00:52:00,159 --> 00:52:02,320
the community can do to help out with some of

1059
00:52:02,360 --> 00:52:04,320
those is that if we are open source project, you

1060
00:52:04,360 --> 00:52:10,880
can contribute. That includes contributing design thoughts, contributing approaches, helping

1061
00:52:10,920 --> 00:52:13,239
us work through like how would we actually do this,

1062
00:52:13,360 --> 00:52:15,920
and even potentially contributing code.

1063
00:52:16,199 --> 00:52:18,320
Speaker 2: Yeah, I think someone who's frustrated because you haven't got

1064
00:52:18,320 --> 00:52:20,639
it yet writing up this is what I would use

1065
00:52:20,679 --> 00:52:24,320
it for, so that you have better case analysis of

1066
00:52:24,360 --> 00:52:27,639
like this is how this customer will implement this? Are

1067
00:52:27,639 --> 00:52:28,519
we headed in that path?

1068
00:52:28,519 --> 00:52:29,840
Speaker 1: Why would you ever want to do that?

1069
00:52:30,039 --> 00:52:34,400
Speaker 4: Yeah? With with multi threading, so that's the like the why,

1070
00:52:34,559 --> 00:52:37,519
and like like what problems should solve? You can also

1071
00:52:37,599 --> 00:52:39,960
help us with contributing and this is how I think

1072
00:52:40,000 --> 00:52:42,039
would be a good way to solve it, even if

1073
00:52:42,079 --> 00:52:44,480
it's a straw man proposal that that is a food

1074
00:52:44,519 --> 00:52:46,639
for a thought. We just went through through this with

1075
00:52:46,719 --> 00:52:49,880
web assembly, multi threading and DOTTA nine, where you know,

1076
00:52:49,920 --> 00:52:53,360
we went through design and you know, get up docs,

1077
00:52:53,360 --> 00:52:57,000
got written and start implementing that design. And for Blazer,

1078
00:52:57,119 --> 00:52:59,000
the design we landed on and look like it's gonna

1079
00:52:59,000 --> 00:53:00,800
be good. This looks So we weren't able to get

1080
00:53:00,800 --> 00:53:02,679
the Blazer part of the work done and DOT and nine,

1081
00:53:02,719 --> 00:53:05,159
so we're still waiting a little bit on that. We pretend,

1082
00:53:05,760 --> 00:53:08,480
but then we got feedback from other UI stacks in

1083
00:53:08,519 --> 00:53:11,559
the ecosystem that use our web assembly support like UNO

1084
00:53:11,639 --> 00:53:14,719
and Avolonia look at look at our looking at our

1085
00:53:14,800 --> 00:53:18,480
multi threading capabilities, and they have valid feedback about whoa

1086
00:53:18,519 --> 00:53:20,840
hold on, like this constraint might be problematic for the

1087
00:53:20,840 --> 00:53:24,239
way we use this feature. And both types of design

1088
00:53:24,239 --> 00:53:28,000
discussions also super valuable, like please look at what we're doing.

1089
00:53:28,079 --> 00:53:30,119
Share you're not every part of the product.

1090
00:53:30,159 --> 00:53:32,519
Speaker 2: Well you yeah, you're living. You provide a framework in

1091
00:53:32,559 --> 00:53:35,880
an ecosystem, don't break the ecosystem, like that's we.

1092
00:53:35,960 --> 00:53:37,920
Speaker 4: Try not to try to make the world a better

1093
00:53:37,920 --> 00:53:38,920
place for the ecosystem.

1094
00:53:39,519 --> 00:53:39,679
Speaker 1: Yeah.

1095
00:53:39,760 --> 00:53:42,000
Speaker 2: Yeah. To imagine a group like you know it's done

1096
00:53:42,039 --> 00:53:43,760
all kinds of great work where they say, hey, we're

1097
00:53:43,760 --> 00:53:45,880
not going to be able to use a new version

1098
00:53:45,920 --> 00:53:48,800
of Blazer based on what you're doing here. Yeah, exactly,

1099
00:53:49,320 --> 00:53:51,840
Well that would be bad. That's bad for everybody.

1100
00:53:52,079 --> 00:53:54,960
Speaker 4: This won't meet our needs, that might make Microsoft's needs.

1101
00:53:55,000 --> 00:53:59,239
And we we want to develop deliver features for the

1102
00:53:59,400 --> 00:54:00,679
entire ecosystem.

1103
00:54:00,760 --> 00:54:04,760
Speaker 2: Not But I think it's just you stepping into introduced

1104
00:54:04,760 --> 00:54:07,679
breaking changes knowing what you're breaking. I'm not saying you

1105
00:54:07,719 --> 00:54:11,400
wouldn't do it, but you want to have those considerations, like,

1106
00:54:11,880 --> 00:54:14,079
here's how big the impact actually is. You don't want

1107
00:54:14,119 --> 00:54:16,239
to ship it and then find out about the impact.

1108
00:54:16,400 --> 00:54:18,880
Speaker 4: Yeah, I mean, breaking changes are one thing, and in

1109
00:54:18,920 --> 00:54:21,840
other cases it's just like having a design that's overly

1110
00:54:22,000 --> 00:54:25,920
constrained or thought about certain scenarios in certain ways, you know,

1111
00:54:25,920 --> 00:54:29,920
adjusting the requirements based on as broad and inclusive an

1112
00:54:29,960 --> 00:54:31,280
audience as we can, we can.

1113
00:54:31,159 --> 00:54:33,280
Speaker 2: Get sure and I could see it'd be worth just

1114
00:54:33,320 --> 00:54:35,840
pushing back and working a little longer and then maybe

1115
00:54:35,880 --> 00:54:37,719
a pass the thresholder it's like, it's not going to

1116
00:54:37,760 --> 00:54:40,280
make this version. Yeah, I mean you're shipping every year,

1117
00:54:40,320 --> 00:54:42,480
which I think has got to be hard. I know

1118
00:54:42,559 --> 00:54:46,760
it's hard receiving new versions every year. So I gotta

1119
00:54:46,760 --> 00:54:49,239
think it's hard on you guys too, pushing these out

1120
00:54:49,280 --> 00:54:51,679
every year, knowing your ship date the second week of

1121
00:54:51,719 --> 00:54:53,280
November every.

1122
00:54:53,079 --> 00:54:55,480
Speaker 4: Time, got a ship one way or another.

1123
00:54:55,599 --> 00:54:58,239
Speaker 2: Yeah, And certainly other teams you talk to where it's like, oh,

1124
00:54:58,320 --> 00:55:01,679
this feature has been worked on, spanning multiple versions before

1125
00:55:01,719 --> 00:55:04,519
we could finally actually turn it on. Like absolutely, that's

1126
00:55:04,599 --> 00:55:07,119
just that's just the reality. Not everything fits into a

1127
00:55:07,199 --> 00:55:10,400
year long development, much less how the target moves like

1128
00:55:10,800 --> 00:55:14,320
you think you know, think about the the FSI. It's

1129
00:55:14,639 --> 00:55:18,840
how many of the features you're currently planning breach FSI

1130
00:55:19,239 --> 00:55:23,719
and need to be reworked to include new security requirements. Yeah,

1131
00:55:24,320 --> 00:55:27,840
all these things are hard, and it's reality tends to

1132
00:55:27,880 --> 00:55:31,239
smack you around, right, And I, for one, having been

1133
00:55:31,280 --> 00:55:33,719
on the side of you ship something that created a

1134
00:55:33,760 --> 00:55:36,599
bunch of problems for folks, I'd rather you wait.

1135
00:55:36,400 --> 00:55:38,760
Speaker 4: It, particularly when it comes to frameworks, because when things

1136
00:55:38,800 --> 00:55:40,400
go into a framework, it's it's hard.

1137
00:55:40,480 --> 00:55:43,360
Speaker 2: You can't ever take them out. Really, Yeah, taking them

1138
00:55:43,360 --> 00:55:45,519
out is way way more arduous.

1139
00:55:45,679 --> 00:55:49,440
Speaker 1: Or convince people not to use that anymore, use this instead.

1140
00:55:49,599 --> 00:55:51,840
Speaker 2: Yeah, that's that's a tough one, because they got working

1141
00:55:51,880 --> 00:55:55,039
code on the old way. It's something to see Steve

1142
00:55:55,079 --> 00:55:57,280
Sanderson's show up in some of these threads and just

1143
00:55:57,280 --> 00:55:58,880
make a couple of notes or something like that. It's like,

1144
00:55:59,280 --> 00:56:04,280
it's like this is as demigod, I blessed this, Like dang,

1145
00:56:04,320 --> 00:56:05,480
you got blessed.

1146
00:56:08,800 --> 00:56:10,320
Speaker 1: All right, Dan, I want to know who plays the

1147
00:56:10,360 --> 00:56:11,360
cello in your family.

1148
00:56:11,840 --> 00:56:15,679
Speaker 4: I play a little bit of the cello. I don't

1149
00:56:15,679 --> 00:56:18,840
play very much anymore. I did do a little like

1150
00:56:18,960 --> 00:56:22,199
talent show concert like a couple months ago. So I

1151
00:56:22,199 --> 00:56:24,679
had it out and was playing it. And I don't

1152
00:56:24,679 --> 00:56:26,079
know if you ever play a string instrument.

1153
00:56:26,159 --> 00:56:27,760
Speaker 1: I tried for a year.

1154
00:56:28,119 --> 00:56:30,920
Speaker 4: Oh yeah, your fingers get raw if you haven't played

1155
00:56:30,960 --> 00:56:33,679
in a while. So I was getting all the red fingertips.

1156
00:56:34,639 --> 00:56:37,519
I played through like high school, a little bit in college,

1157
00:56:37,559 --> 00:56:40,400
and definitely petered off after that. But I still have

1158
00:56:40,480 --> 00:56:43,320
my cello, still occasionally break it out.

1159
00:56:42,320 --> 00:56:46,599
Speaker 1: And yeah, I noticed the case. That's why everybody can't

1160
00:56:46,639 --> 00:56:49,159
see this because it's the radio show. But but there's

1161
00:56:49,159 --> 00:56:51,159
a case in the corner. Yeah. I tried it for

1162
00:56:51,199 --> 00:56:52,960
about a year. I was already playing guitar, so I

1163
00:56:53,000 --> 00:56:56,119
didn't have the fingertip problem, but the stretch, Like you know,

1164
00:56:56,679 --> 00:57:00,000
my hands are relatively small, and the figure your hands

1165
00:57:00,039 --> 00:57:03,920
sorry for a cello or bass player. The smaller your

1166
00:57:03,920 --> 00:57:07,599
fingers are for violin, the better. But anyway, I think

1167
00:57:07,599 --> 00:57:07,800
it was.

1168
00:57:07,800 --> 00:57:09,840
Speaker 2: A joke by Frank Carlwoods told me, says, you know

1169
00:57:09,840 --> 00:57:12,360
what the difference between a violin and a viola is

1170
00:57:12,400 --> 00:57:18,840
the viola burns longer. This is very How did you

1171
00:57:18,920 --> 00:57:27,800
know this? We should test it, all right, Dan? Anything

1172
00:57:27,840 --> 00:57:29,000
else before we jump off?

1173
00:57:29,519 --> 00:57:33,599
Speaker 4: I get get market calendar for fort comp November. That's

1174
00:57:33,599 --> 00:57:35,960
when we'll be having a big the big ship party.

1175
00:57:36,039 --> 00:57:36,800
So we look forward.

1176
00:57:36,880 --> 00:57:40,960
Speaker 1: You got early bits available now you can early what sorry,

1177
00:57:41,119 --> 00:57:43,199
early bits are early bits available now?

1178
00:57:43,280 --> 00:57:45,960
Speaker 4: Oh yeah, the release candidate is already the first release

1179
00:57:46,000 --> 00:57:49,239
Candidate's already shipped and here in just a few days.

1180
00:57:49,239 --> 00:57:51,320
Maybe by the time this this episode air, by.

1181
00:57:51,199 --> 00:57:53,400
Speaker 2: The time this is this publishes end of October, there'll

1182
00:57:53,400 --> 00:57:56,480
be they'll be you'll be second release candiate too, which

1183
00:57:56,519 --> 00:57:59,360
really means your interest away. Then it will be a

1184
00:57:59,400 --> 00:58:01,400
couple of weeks before dot dot com at that point,

1185
00:58:01,760 --> 00:58:03,320
so it'll be final.

1186
00:58:03,960 --> 00:58:07,239
Speaker 1: So awesome. Our timing works. Thank you, Dan, always a pleasure.

1187
00:58:07,360 --> 00:58:09,440
Speaker 2: Good to see you, frank for having me talking with

1188
00:58:09,480 --> 00:58:10,599
you guys. You bet all right.

1189
00:58:10,639 --> 00:58:30,559
Speaker 1: We'll talk to you next time on dot net rocks.

1190
00:58:34,039 --> 00:58:36,719
Dot net Rocks is brought to you by Franklin's Net

1191
00:58:36,880 --> 00:58:40,840
and produced by Pop Studios, a full service audio, video

1192
00:58:40,880 --> 00:58:44,960
and post production facility located physically in New London, Connecticut,

1193
00:58:45,199 --> 00:58:50,039
and of course in the cloud online at pwop dot com.

1194
00:58:50,199 --> 00:58:52,360
Speaker 3: Visit our website at d O T N E t

1195
00:58:52,559 --> 00:58:56,599
R O c k S dot com for RSS feeds, downloads,

1196
00:58:56,760 --> 00:59:00,440
mobile apps, comments, and access to the full archive going

1197
00:59:00,480 --> 00:59:03,880
back to show number one, recorded in September two thousand

1198
00:59:03,880 --> 00:59:04,159
and two.

1199
00:59:04,760 --> 00:59:07,119
Speaker 1: And make sure you check out our sponsors. They keep

1200
00:59:07,199 --> 00:59:10,360
us in business. Now go write some code, See you

1201
00:59:10,400 --> 00:59:14,119
next time. You got JAD middle vans, the

1202
00:59:20,840 --> 00:59:21,239
Speaker 3: Taxes,