1 00:00:01,000 --> 00:00:04,759 How'd you like to listen to dot net rocks with no ads? Easy? 2 00:00:05,320 --> 00:00:09,880 Become a patron For just five dollars a month you get access to a private 3 00:00:10,000 --> 00:00:14,400 RSS feed where all the shows have no ADS. Twenty dollars a month will 4 00:00:14,400 --> 00:00:18,800 get you that and a special dot net Rocks patron mug. Sign up now 5 00:00:18,839 --> 00:00:23,760 at Patreon dot dot net rocks dot com. Hey Carlin, Richard Here, 6 00:00:24,079 --> 00:00:29,280 As you may have heard, NDC is back offering their incredible in person conferences 7 00:00:29,320 --> 00:00:33,240 around the world, and we'd like to tell you about them. NDC Oslow 8 00:00:33,240 --> 00:00:37,039 will be me twenty first through the twenty fifth. Go to NDC Oslo dot 9 00:00:37,119 --> 00:00:42,759 com to register. NDC Copenhagen is happening August twenty seventh through the thirty first. 10 00:00:43,320 --> 00:00:48,960 Go to NDC Copenhagen dot com for more information. NDC Porto is happening 11 00:00:49,000 --> 00:00:53,280 October sixteenth through the twentieth. The early bird discount for DC Porto ends July 12 00:00:53,560 --> 00:00:58,280 twenty first. Go to Eddcporto dot com to register and check out the full 13 00:00:58,320 --> 00:01:18,840 lineup of conferences at DC conferences dot com. Hey, welcome back to dot 14 00:01:18,920 --> 00:01:23,319 net Rocks. This is Carl Franklin and this is Richard Campbell and what it's 15 00:01:23,359 --> 00:01:25,959 been a Whileston. So we recorded, but we're kind of recording this right 16 00:01:26,040 --> 00:01:27,359 up to the wire, aren't we. I love it when we have a 17 00:01:27,359 --> 00:01:30,319 show the week of that. Yeah, we live the Hopper get a little 18 00:01:30,359 --> 00:01:34,280 low. I blame myself. I was traveling a lot. Well, you 19 00:01:34,319 --> 00:01:36,480 know, can't blame me for traveling. Yeah. I went down in New 20 00:01:36,599 --> 00:01:38,200 Zealand, Australia. Then I came home for like two days, and then 21 00:01:38,200 --> 00:01:41,840 I went over to Wales. So I do not know what time zone I'm 22 00:01:41,840 --> 00:01:45,040 in. It's not a thing. I got back yesterday. I've got a 23 00:01:45,079 --> 00:01:49,000 little story for you, and that is the construction has started on my new 24 00:01:49,040 --> 00:01:53,799 home studio, which I'm affectionately calling Poop three point zero. Okay, that's 25 00:01:53,840 --> 00:01:57,400 cool. So this is in that giant garage you have, the giant garage 26 00:01:57,439 --> 00:02:00,280 Chat. It's a twelve hundred square foot ga and I'm taking up more than 27 00:02:00,319 --> 00:02:05,159 half of it with in the back and I'm gonna give it the same treatment 28 00:02:05,200 --> 00:02:07,439 that we did in New London in the originals, kind of Yeah, you're 29 00:02:07,479 --> 00:02:12,159 gonna go right again. Oh yeah, same material and everything. Oh cool. 30 00:02:12,800 --> 00:02:15,680 Yeah. So they're in there now pulling out the insulation and I'm going 31 00:02:15,719 --> 00:02:19,560 to document it on our Facebook page. That's cool, WoT Productions. All 32 00:02:19,599 --> 00:02:30,240 right, enough chit chat, let's start off with Better Know framework. Well, 33 00:02:30,599 --> 00:02:34,639 we all know what the poly project is. If you've been listening to 34 00:02:34,719 --> 00:02:39,039 this show, and if you haven't used it, you really ought to check 35 00:02:39,080 --> 00:02:44,639 it out. Polly is a tool that you can use for resilience strategies. 36 00:02:44,680 --> 00:02:49,599 So what happens when transient errors happened, your network goes down, or some 37 00:02:49,719 --> 00:02:53,599 network endpoint is busy or something like that. We started talking about it on 38 00:02:53,639 --> 00:02:57,719 dot net Rocks and then fv next became a shepherd of it. Then it 39 00:02:57,840 --> 00:03:02,759 got into the dot Net Foundation, and then Polly went into dot net two 40 00:03:02,800 --> 00:03:07,800 point one with HTTP Client Factory. So needs to say it's been a few 41 00:03:07,879 --> 00:03:14,199 years. There's we actually haven't had many updates to it for the past couple 42 00:03:14,240 --> 00:03:17,719 of years. Well, there's also a point where it's done right, Well 43 00:03:17,800 --> 00:03:23,759 you'd think it's done, but there's a bit of non trivial technical debt, 44 00:03:24,080 --> 00:03:30,039 including lack of cancelation tokens and in some operations of a lack of file a 45 00:03:30,120 --> 00:03:36,560 sync support for all callbacks, and some performance issues. So what happened is 46 00:03:37,080 --> 00:03:43,439 the dot net team built a prototype version of Polly that simplifies Polly's API surface 47 00:03:43,479 --> 00:03:50,879 area with a single eye resilience strategy interface that's responsible for executing all the poly 48 00:03:51,000 --> 00:03:55,159 scenarios and addresses the performance issues with excellent results. In fact, in the 49 00:03:55,159 --> 00:04:00,520 early test, the new changes resulted in CPU overhead reduction of eighty percent. 50 00:04:00,960 --> 00:04:06,479 That's nice numbers. Yeah, And additionally the proof of concept significantly reduced allocations 51 00:04:06,560 --> 00:04:13,879 by large factors. So these are all great optimizations. What's interesting is that 52 00:04:14,919 --> 00:04:19,319 it's completely backward compatible and it hasn't happened yet. So what happens is Joel 53 00:04:19,439 --> 00:04:24,160 Human has written this blog post that we're going to link to, and this 54 00:04:24,240 --> 00:04:27,759 is eighteen thirty eight, So if you go to eighteen thirty eight pop dot 55 00:04:27,800 --> 00:04:34,319 me, you'll see the link. And we're looking for feedback about version eight, 56 00:04:34,439 --> 00:04:39,800 which is the up and coming version with all these changes. And so 57 00:04:39,839 --> 00:04:43,040 that's what we want. Want you to take it for a spin, you 58 00:04:43,079 --> 00:04:46,920 know, check it out, and let us know you know what you like, 59 00:04:46,040 --> 00:04:48,480 what you don't like about it. I love me a V eight. 60 00:04:49,040 --> 00:04:57,879 Yes, so's it's really exciting and I hope people can jump in and contribute. 61 00:04:58,279 --> 00:05:00,560 Who's talking to us today, Richard, I grabbed a comment off the 62 00:05:00,600 --> 00:05:04,439 show seventeen ninety four. That's the one we did with jemmia Abu when we 63 00:05:04,439 --> 00:05:10,639 were I think we were at NDC in London. This is back in early 64 00:05:10,680 --> 00:05:14,079 twenty twenty two, and of course we talked a little bit. We were 65 00:05:14,079 --> 00:05:19,519 talking about different front end frameworks from Vanilla JavaScript all the way through Blazer, 66 00:05:20,079 --> 00:05:25,399 and Josh Dabashaw had this great comedy said, I've been working almost exclusively with 67 00:05:25,519 --> 00:05:29,720 web components in Blazer for almost two years now, and the two work really 68 00:05:29,720 --> 00:05:31,279 well together. We've even gone so far as to wrap some of my web 69 00:05:31,279 --> 00:05:38,720 components in Blazer components to augment them with server's side code. Fancy. Initially 70 00:05:38,759 --> 00:05:42,519 I went down the web component route because when the orders came from on High 71 00:05:42,560 --> 00:05:46,519 to use Blazer only a few months after the first release, those are early 72 00:05:46,600 --> 00:05:50,000 days, I wasn't convinced it was going to hold up under a load. 73 00:05:50,279 --> 00:05:55,600 I wanted a framework agnostic escape hatch, and I came upon the at the 74 00:05:55,680 --> 00:06:00,120 time new Microsoft Fast Element library. Luckily did hold up, and we've been 75 00:06:00,160 --> 00:06:03,600 massively productive with our new stack. And then he goes on to say, 76 00:06:03,680 --> 00:06:09,319 y'all should interview Rob Eisenberg or something in a fast team. They're doing a 77 00:06:09,319 --> 00:06:14,120 lot of great stuff with Web and Blazer components for fluent. And by the 78 00:06:14,160 --> 00:06:19,000 way, Flash is not dead. Yes it is. Bite your tongue, 79 00:06:19,240 --> 00:06:25,600 don't believe it. You can use Flash application code to publish to canvas with 80 00:06:25,639 --> 00:06:30,879 an adapter library called create JS, the same syntax as action script three, 81 00:06:30,959 --> 00:06:34,319 because everybody loves action script, Carl, everybody loves it. My god, 82 00:06:34,560 --> 00:06:39,040 I use this to make a computer based training modules at my last gig only 83 00:06:39,040 --> 00:06:41,439 three years ago, and it worked really, really well. I just have 84 00:06:41,519 --> 00:06:45,759 flashbacks to speaking of flashbacks, I have to say flashbacks. He didn't really 85 00:06:45,839 --> 00:06:49,399 I did. I have flashbacks to my stepdaughter in high school in the nineties 86 00:06:49,959 --> 00:06:56,560 talking about how her web class was all flash. They didn't even talk about 87 00:06:56,680 --> 00:06:59,959 HTML. It was easy, and I wanted to go down there and ring 88 00:07:00,079 --> 00:07:04,959 neck guy's neck. Well, you know, people were looking for easy ways 89 00:07:04,959 --> 00:07:08,399 to do things. There's about it. Yeah, back at the time. 90 00:07:08,439 --> 00:07:11,040 So Josh, thank you so much for your comment, and a copy music 91 00:07:11,079 --> 00:07:13,279 Coby is on its way to you. If you'd like a copy of music, 92 00:07:13,279 --> 00:07:15,319 go by write a comment on the website at dot dot rocks dot com 93 00:07:15,439 --> 00:07:18,079 or on the Facebook's if you publish every show there, and if you comment 94 00:07:18,160 --> 00:07:19,879 there and I read it on the show, we'll say, do you a 95 00:07:19,879 --> 00:07:24,079 copy music copy and you can follow us on Twitter if you want, but 96 00:07:24,160 --> 00:07:28,279 we really like you to follow us on Mastodon. I'm at Carl Franklin at 97 00:07:28,279 --> 00:07:32,439 tech hub dot social, and I'm rich Campbell at mastadon dot social and send 98 00:07:32,480 --> 00:07:36,399 us a two and check it out. Check out maskdon doesn't even matter. 99 00:07:36,399 --> 00:07:39,600 If it's funny, it's pretty good. Yeah, just send us the tute. 100 00:07:40,199 --> 00:07:42,879 Some guy just today said, hey, have you been saying send us 101 00:07:42,879 --> 00:07:45,439 a tute? So here it is. I'm checking out Mastodon. Thanks, 102 00:07:45,560 --> 00:07:51,240 thanks for the reference. Okay, let's uh bring on our guests. Steve 103 00:07:51,319 --> 00:07:56,959 Sanderson doesn't need any introduction. He's he would say, yeah, I'm Steve. 104 00:07:57,000 --> 00:08:00,319 I'm a developer at Microsoft. But what he really is is the ventor 105 00:08:00,399 --> 00:08:05,600 of freaking Blazer and all other sorts of cool things and how your nelson is 106 00:08:05,600 --> 00:08:09,120 with him, and he's a senior software engineer on the ESPN team. Welcome, 107 00:08:09,199 --> 00:08:15,920 guys. I can't imagine why you came around. Hi there, Carl, 108 00:08:16,000 --> 00:08:18,800 Hello Richard I am glad to be back and chatting to you again. 109 00:08:20,160 --> 00:08:24,759 Um yet you want to say hi everyone? I'm Ahavier. I work on 110 00:08:24,319 --> 00:08:28,600 Blaze on ESPN D with Steve and I'm happy to be here. Steve, 111 00:08:28,720 --> 00:08:31,360 how did you become so humble? Were you always this way? I think 112 00:08:31,759 --> 00:08:35,440 you know, I've I've practiced for many years to become as humble as I 113 00:08:35,480 --> 00:08:39,360 am now, and it's definitely one of the greatest accomplishments I think in human 114 00:08:39,399 --> 00:08:46,080 history. Astounding. It's astounding. I mean, so, were you like 115 00:08:46,519 --> 00:08:52,720 much more braggadocious, like in school? I was a very very quiet person 116 00:08:52,720 --> 00:08:56,440 at school. Yeah. Yeah, Well, anyway, that's not why you're 117 00:08:56,480 --> 00:08:58,879 here. We're here to talk about what Blazer United or something like that. 118 00:09:00,279 --> 00:09:01,639 Yeah, yeah, so you've heard of it. What do you think so 119 00:09:01,720 --> 00:09:05,679 far? I have? Well, I haven't played with the bits, but 120 00:09:05,159 --> 00:09:11,399 everything that I see I love and I can't wait. I can't wait for 121 00:09:11,399 --> 00:09:15,320 the first preview. So we better tell people what the heck Placer United is? 122 00:09:15,519 --> 00:09:18,159 Yeah? What is it? Okay? Have you had you want to 123 00:09:18,159 --> 00:09:22,360 explain the idea? Sure? So right now? When you do place or 124 00:09:22,440 --> 00:09:26,600 you have to choose between server and client and the idea of Place or United 125 00:09:26,960 --> 00:09:31,320 is essentially removing that choice that you may need to make ahead of time and 126 00:09:31,600 --> 00:09:35,840 enabling you to make that decision on a more granular level, not at the 127 00:09:35,960 --> 00:09:41,240 level of your app, but on a per component basis. So we are 128 00:09:41,279 --> 00:09:46,840 trying to enhance place or with server side rendering similar to how you do NBC 129 00:09:48,039 --> 00:09:52,360 or recur pages, and on top of that being able to render interactive islands 130 00:09:52,399 --> 00:09:56,919 of functionality within your app, so that you can have as an application that 131 00:09:58,039 --> 00:10:01,960 starts as a server and the app that has some more modern take on server 132 00:10:03,039 --> 00:10:09,120 side rendering with things like a streaming rendering and that then can evolve on continue 133 00:10:09,159 --> 00:10:15,720 on its path to returned activity through either server components or web assembly, and 134 00:10:16,240 --> 00:10:22,039 essentially trying to avoid forcing you to make a choice and letting you choose whatever 135 00:10:22,159 --> 00:10:26,919 fits best for your scenarios. Yeah. So the thing that catches everyone's here 136 00:10:26,960 --> 00:10:31,559 the most, I think is this automnode where you start as a Blazer server 137 00:10:31,639 --> 00:10:37,639 application and then in the background the web assembly DLLs are loading, and when 138 00:10:37,679 --> 00:10:45,519 they're loaded, it switches over to a web assembly component or page. But 139 00:10:46,000 --> 00:10:50,200 I don't want to I don't want to glaze over the server side rendering thing, 140 00:10:50,000 --> 00:10:54,399 and I kind of want to talk about that and how it differs from 141 00:10:56,759 --> 00:11:01,399 MBC and how it differs from blazers over. Yeah, can we do a 142 00:11:01,440 --> 00:11:05,840 why do you care? Like? Is this about speeding up the startup time? 143 00:11:05,240 --> 00:11:09,039 Yeah? It really comes down to you. So I guess one way 144 00:11:09,080 --> 00:11:13,360 to think about at a very high level is that we want Blazer to be 145 00:11:13,679 --> 00:11:18,080 suitable for all WebUI scenarios, which it isn't today, right, if we're 146 00:11:18,080 --> 00:11:22,879 honest, Blazer is great for certain situations, but not all of them. 147 00:11:22,159 --> 00:11:28,200 Prior to dot neet a like, it's great for richly interactive sites that are 148 00:11:28,240 --> 00:11:31,600 so rich that it's worth downloading a dotnet runtime into someone's browser and making them 149 00:11:31,639 --> 00:11:35,639 wait for you know, a second or two seconds or something before before it's 150 00:11:35,639 --> 00:11:39,000 ready. All for scenarios which are really read and you want to run them 151 00:11:39,000 --> 00:11:43,840 interactively on a server, and that's cool, but that's not all of web 152 00:11:43,879 --> 00:11:46,240 development. That's probably like, you know, fifty percent of web development or 153 00:11:46,279 --> 00:11:50,279 something, And the other fifty percent is you just want to send some HTML 154 00:11:50,279 --> 00:11:54,480 to people's browsers as fast as possible with the lowest possible server overhead, and 155 00:11:54,559 --> 00:11:58,639 it's a stateless request. Response thing, and Blazer has not been suitable for 156 00:11:58,679 --> 00:12:03,759 that in the past. But we are greedy and we want to eat all 157 00:12:05,080 --> 00:12:09,120 web UI scenarios, so we're coming for the other fifty percent. We would 158 00:12:09,120 --> 00:12:15,120 like all the web please. Yeah, all right, I hear that humility 159 00:12:15,200 --> 00:12:20,639 kind of right, But it's not about us. It's about the customers, 160 00:12:20,679 --> 00:12:28,519 right. People are spending their time building their web applications and at the moment 161 00:12:28,519 --> 00:12:31,879 they're forced into this choice up front, like am I orienting stuff around stateless 162 00:12:31,919 --> 00:12:37,759 server rendering or am I oriented and get around interactive SPA type programming. And 163 00:12:37,840 --> 00:12:39,919 because you have to make that choice, like have you I said, you 164 00:12:39,000 --> 00:12:43,679 choose once at the beginning, you're then kind of stuck with that and you 165 00:12:43,720 --> 00:12:46,519 can't really cross that chasm easily. But what we've realized, and what we've 166 00:12:46,519 --> 00:12:50,759 seen from some other similar technologies, is that it is possible to have one 167 00:12:50,919 --> 00:12:56,080 UI technology that will cover both of these scenarios, so that you only have 168 00:12:56,159 --> 00:13:00,840 to do your work once you write your component and it can work in either 169 00:13:00,919 --> 00:13:03,399 this interactive mode or the stateless server mode, and then we can do all 170 00:13:03,440 --> 00:13:05,919 the advanced stuff on top of that that. Have you listed a bunches of 171 00:13:05,919 --> 00:13:09,559 stuff where you know, we have different islands that some of them are interactors, 172 00:13:09,559 --> 00:13:13,639 some of an art some of a server, some web assembly, some 173 00:13:13,759 --> 00:13:16,559 dynamically switch from one to the other. You know, all these different advanced 174 00:13:16,559 --> 00:13:20,440 things. But ultimately it comes down to the fact that we want to cover 175 00:13:20,519 --> 00:13:24,039 all the scenarios with a single programming model, single UI technology. Is there 176 00:13:24,080 --> 00:13:28,399 a case for a mixed mode? I mean it isn't ideally everything client you 177 00:13:28,440 --> 00:13:31,799 just as long as you don't have to wait for it. Mum. There 178 00:13:31,840 --> 00:13:37,000 are advantages right, well, yeah, advantages. There's advantages to both, 179 00:13:37,039 --> 00:13:39,799 aren't there. There's avantages to the server side, and that you don't have 180 00:13:39,840 --> 00:13:43,720 to hide your secrets. You don't have to have an API layer for example. 181 00:13:43,840 --> 00:13:46,600 Yeah, you have you have your data and your state alreadyly available on 182 00:13:46,639 --> 00:13:50,639 the server. You don't have to go through all the hussle office to be 183 00:13:50,720 --> 00:13:54,519 client, all the things that you need to deal with like authorization, all 184 00:13:54,519 --> 00:13:58,679 that stuff, because it already is on the server. So it's one of 185 00:13:58,720 --> 00:14:03,559 the things that missus to realize me in many cases when you using Blazer server 186 00:14:03,960 --> 00:14:07,080 is that it's really really convenient because you have everything right at the top of 187 00:14:07,080 --> 00:14:11,360 your hand. The moment you move to web assembly or do others of framework, 188 00:14:11,600 --> 00:14:13,840 then you have this layer where you need to be serializing everything, and 189 00:14:15,080 --> 00:14:18,279 as much as you can try to smooth over that, you still need to 190 00:14:18,320 --> 00:14:22,879 think about it. So if you have something that is highly interactive, then 191 00:14:22,879 --> 00:14:26,679 it makes sense for example, to be web assembly. If you are handling 192 00:14:26,679 --> 00:14:31,360 song operation on the server, then it might make sense for you to be 193 00:14:31,399 --> 00:14:35,679 able to plug an a component that that's everything on the server. So Richard's 194 00:14:35,759 --> 00:14:39,120 question is really valid here in that. Okay, I see the benefit to 195 00:14:39,159 --> 00:14:41,360 Blazer server, but if you're going to end up that place a web assembly 196 00:14:41,399 --> 00:14:46,120 anyway, why would you need to start with blazers server. Well, there's 197 00:14:46,120 --> 00:14:50,080 a couple of advantagies. One of them is the startup time that we've alluded 198 00:14:50,120 --> 00:14:52,519 to. So with web assembly, you know, if the user's got a 199 00:14:52,519 --> 00:14:56,360 fast network connection, then hopefully the app can get started within a couple of 200 00:14:56,399 --> 00:15:01,440 seconds, but you know can't absolutely that, especially if they're on a slow 201 00:15:01,480 --> 00:15:05,039 network connection. Whereas a Blazer server app is going to start instantly there's nothing 202 00:15:05,080 --> 00:15:09,200 really to download, so you've got that startup time. The other thing is 203 00:15:09,279 --> 00:15:15,320 all these architectural advantages that have you mentioned where you're trying to talk to your 204 00:15:15,399 --> 00:15:18,360 database, You can just do that right. Your code's already on the server. 205 00:15:18,519 --> 00:15:20,480 It can just stop to the database straightaway, no need to bother writing 206 00:15:20,519 --> 00:15:24,879 API layers. It's just a very very productive environment to be in. But 207 00:15:24,919 --> 00:15:30,840 if it's going to eventually end up as a Websemily application in automode, you're 208 00:15:30,840 --> 00:15:35,039 still going to have to have the API layer and all of the things that 209 00:15:35,759 --> 00:15:39,960 we are required for a Websemily application, right, Oh, yeah, yeah, 210 00:15:39,960 --> 00:15:43,399 you are right. Yeah. So if your intention is to have an 211 00:15:43,399 --> 00:15:48,159 application that genuinely works in birth modes and is able to switch between them, 212 00:15:48,159 --> 00:15:52,320 then you do have to be concerned about birth server side and client side concerns. 213 00:15:52,320 --> 00:15:58,480 And at that point it's a pure startup time startup time optimization. Yeah, 214 00:15:58,600 --> 00:16:02,519 yeah, there's and it's almost a philosophical question of here is that which 215 00:16:02,559 --> 00:16:07,639 would consume lest bandwidth staying strictly server side and you know, interacting the client 216 00:16:07,720 --> 00:16:12,080 back and forth versus getting all the client down and its interacting at the API 217 00:16:12,200 --> 00:16:17,039 level. Because I could almost see as one of the be different commigurations based 218 00:16:17,039 --> 00:16:21,399 on bandwidth constraints or bandwidth cost constraints yep, yep. There's there's sons are 219 00:16:21,399 --> 00:16:25,559 trade us to make. There's the bandwidth, there's the startup CPU time. 220 00:16:25,679 --> 00:16:30,000 There's how much time and memory you're consuming on the server. There's how much 221 00:16:30,000 --> 00:16:36,799 state you might need to transfer. There's the latency of UI interactions that they 222 00:16:36,840 --> 00:16:42,000 all put you at different points on preferring server or client side code. And 223 00:16:42,080 --> 00:16:45,679 we can't decide for all applications how it should be. And that's part of 224 00:16:45,720 --> 00:16:51,000 the goals with this new programming model is that developers can make that decision for 225 00:16:51,039 --> 00:16:53,399 themselves on a very fine ground basis. It doesn't have to be the entire 226 00:16:53,440 --> 00:16:56,559 project is just server side, or the entire thing is web assembly. But 227 00:16:56,679 --> 00:17:03,840 you could have individual components where you say this one needs a superlo latency interaction 228 00:17:03,919 --> 00:17:07,319 like a text data to or something and something else which is just like a 229 00:17:07,359 --> 00:17:11,640 list of products. Maybe that's suddenly going to update once in a few minutes. 230 00:17:11,839 --> 00:17:14,799 You will just run that server side, all right. Getting back to 231 00:17:14,839 --> 00:17:21,480 my question about the differences between server side rendering and MBC and Blazer Server, 232 00:17:22,359 --> 00:17:30,079 what are the differences there? Ye, So Blazer United or server side Rendering 233 00:17:30,319 --> 00:17:34,880 Laser is an equivalent model to MBC and racer pages in the sense that everything 234 00:17:34,920 --> 00:17:40,240 is server side rendered. There is no JavaScript. The browser is the one 235 00:17:40,759 --> 00:17:48,640 talking to the server, and the main advantage of using racer components over NBC 236 00:17:48,759 --> 00:17:53,079 or race or pages is that then that component can also work on web assembly 237 00:17:53,200 --> 00:17:59,480 and Blazer or server and you're using a single component model or a single programming 238 00:17:59,480 --> 00:18:03,079 model to target all three scenarios. So the goal here as a stick mensions 239 00:18:03,200 --> 00:18:10,960 is to try and reach the broader set of people possible. And pretty much 240 00:18:11,079 --> 00:18:15,559 nothing beats server render apps in terms of getting data to the your customer and 241 00:18:15,680 --> 00:18:22,880 being able to do simple interactions. So what's the difference between a Razor component 242 00:18:22,920 --> 00:18:26,480 in a place of server application that takes some data and some HDN splits it 243 00:18:26,519 --> 00:18:33,119 down and just server side rendering and place of United Yeah, so the difference 244 00:18:33,200 --> 00:18:37,000 is the interaction. The interaction in a place or server app happens completely on 245 00:18:37,039 --> 00:18:41,279 the server. We literally delegate the event that happens in the browser and send 246 00:18:41,279 --> 00:18:45,799 it to the server. While in a server render app, okay, is 247 00:18:45,839 --> 00:18:51,400 the browser actually using the standard estemail and web technologies to serve a foreign post 248 00:18:51,480 --> 00:18:55,920 that then we traditionally processed like you would do in NBC or racer pages. 249 00:18:56,200 --> 00:18:59,799 Okay, so there's no circuit, I guess you could say, and just 250 00:19:00,160 --> 00:19:03,279 yeah, exactly right, that's the circuit. Happens in the circuit is the 251 00:19:03,319 --> 00:19:08,480 signal our connection plus some metadata around it. They call a circuit, right, 252 00:19:08,599 --> 00:19:12,599 yep. Yeah, And so there's a circuit when you have a server 253 00:19:12,680 --> 00:19:19,759 side blaser component or page, but not when you have either web assembly obviously 254 00:19:19,960 --> 00:19:26,279 or server side rendering exactly and those and as we talked about this on Blazer 255 00:19:26,359 --> 00:19:30,759 trains to you, I was concerned about, you know, multiple circuits with 256 00:19:30,839 --> 00:19:36,039 multiple components, and there's only ever one circuit and it's either on or it's 257 00:19:36,119 --> 00:19:37,799 not. Right, Yeah, that's right. Yeah. And the intention is 258 00:19:37,839 --> 00:19:41,880 that we have that circuit for the minimal amount of time that we need to 259 00:19:42,079 --> 00:19:45,799 so as the user navigates around, if they happen to go to a location 260 00:19:45,880 --> 00:19:51,559 that has a server ended component, then a circuit will start up and as 261 00:19:51,559 --> 00:19:53,319 soon as they navigate away from that, it can go away, which means 262 00:19:53,359 --> 00:19:59,279 that the amount of time that you spend holding open a connection to the server 263 00:19:59,440 --> 00:20:03,759 is kept as small as it kind of that reduces the costs for the web 264 00:20:03,799 --> 00:20:07,759 developer, but it also gives you certain resilience benefits as well. So whenever 265 00:20:07,799 --> 00:20:11,160 you don't have a circuit, you don't have to worry about things like you 266 00:20:11,200 --> 00:20:15,680 know what if they go into a tunnel and lose their three G connection areas. 267 00:20:17,839 --> 00:20:21,559 So yeah, it just becomes a traditional website as soon as the circuit 268 00:20:21,599 --> 00:20:26,039 goes away. Back to HDB keep alive. So let's talk about that dreaded 269 00:20:26,680 --> 00:20:32,039 pale white reload page that happens when the circuit gets broken in a Blazer server 270 00:20:32,119 --> 00:20:36,480 application. If you lose the circuit for whatever reason, the Internet goes down, 271 00:20:36,559 --> 00:20:38,640 or Steve said, you go through a tunnel. You know, it 272 00:20:38,880 --> 00:20:44,359 tries to reconnect and if it can't then you have to refresh the page or 273 00:20:44,400 --> 00:20:48,200 whatever. So let's say in the scenario where we have mixed things, maybe 274 00:20:48,240 --> 00:20:56,440 we have one page that's a server Blazer server page, another page that's server 275 00:20:56,519 --> 00:21:02,200 side rendered or web assembly or whatever it's you'ld only run into that issue if 276 00:21:02,200 --> 00:21:06,519 you went to that page. What if you have a rendered page that has 277 00:21:06,559 --> 00:21:12,319 just a component, a Blazer component that's a Blazer server component on it, 278 00:21:12,839 --> 00:21:17,160 and you lose the circuit, does the whole page go wait? Or is 279 00:21:17,160 --> 00:21:21,920 it just that little component area or does it We don't know yet, right, 280 00:21:21,920 --> 00:21:25,359 We haven't implemented that, right, If you've got a design in mind 281 00:21:25,359 --> 00:21:26,920 for that, I think it's a bit of an open question. That's cool. 282 00:21:27,039 --> 00:21:32,880 Yeah, yeah, say so it must work perfectly an implemented yet yeah 283 00:21:32,960 --> 00:21:37,119 yeah. Now you should understand and listeners should understand that we are at an 284 00:21:37,160 --> 00:21:38,960 early stage of design right now. We've got a good prototype and we did 285 00:21:40,000 --> 00:21:45,000 some cool demo videos, but the real implementation we've only just got started on 286 00:21:45,079 --> 00:21:48,880 in the last month, and there's tons of open questions and we are looking 287 00:21:48,920 --> 00:21:52,720 for a lot of feedback on many aspects of the design. People can follow 288 00:21:52,759 --> 00:21:55,559 along and get up and see the work as it goes in with prs, 289 00:21:55,599 --> 00:21:59,400 and we often write things in the PR description which is like open question what 290 00:21:59,440 --> 00:22:03,160 should happen and blah blah blah, And it's great when people come along and 291 00:22:03,200 --> 00:22:06,839 give us their feedback on that. And that thing that you've just raised there 292 00:22:06,880 --> 00:22:10,759 is exactly the sort of thing that we still are you know, design is 293 00:22:10,799 --> 00:22:15,000 pending on that, right, and you're targeting the dot net eight timeframes, 294 00:22:15,000 --> 00:22:18,519 so November of twenty twenty three, that's right, Yeah, yeah, And 295 00:22:18,559 --> 00:22:22,680 I say targeting genuinely say like some features will make it as some features will 296 00:22:22,720 --> 00:22:26,319 not, Like software is complicated and it's a preview out yet or no. 297 00:22:26,440 --> 00:22:30,200 The first preview that you're going to see something of this is Dotnet eight preview 298 00:22:30,240 --> 00:22:33,680 three. I don't know the release state, but we've just gone through the 299 00:22:33,720 --> 00:22:37,079 CD complete point for that at the end of last week, so it's probably 300 00:22:37,079 --> 00:22:37,680 a month away or something. I don't know have yet. Do you know 301 00:22:37,759 --> 00:22:42,279 in it ships, it's just another pretty regular cavens. I don't have the 302 00:22:42,359 --> 00:22:48,279 exact day, but every month. I used to be more worried about done 303 00:22:48,400 --> 00:22:51,720 previews, but I'm not anymore because I know it's ships every month. They're 304 00:22:51,799 --> 00:22:55,640 like clockwork. Yeah yeah, yeah. You stop having that pressure to get 305 00:22:55,680 --> 00:22:59,599 everything done for a given release. You know there's just another release coming. 306 00:22:59,680 --> 00:23:03,640 Better make it right. I said, to make the deadline you really want 307 00:23:03,680 --> 00:23:08,319 to get it like in previous seven rather than But yes, I didn't have 308 00:23:08,319 --> 00:23:12,480 the cojones to actually do the nightly build and try it out. Yeah No, 309 00:23:12,519 --> 00:23:17,240 I wouldn't really recommend most people to bother trying to get the prototype code 310 00:23:17,279 --> 00:23:19,839 runningcause you do have to build the whole ESPNT Core repo and yeah, it's 311 00:23:19,880 --> 00:23:22,720 not that easy, to be honest with you, but yeah, hopefully it's 312 00:23:22,720 --> 00:23:26,799 only a few weeks away until some of the first parts of server rendering show 313 00:23:26,880 --> 00:23:30,440 up. It'll be fairly basic in the first prev three that we won't have 314 00:23:30,440 --> 00:23:36,119 streaming rendering or even the ability to put interactive components on the page. But 315 00:23:36,160 --> 00:23:40,599 you'll start seeing some of the core APIs come together and this is being built 316 00:23:40,680 --> 00:23:45,720 in the asp net core gethub repository, Like, that's where that's where I 317 00:23:45,799 --> 00:23:48,200 see the issues, Like, that's where folks should be going if they want 318 00:23:48,200 --> 00:23:51,640 to participate. That's absolutely right, Yeah, yeah, absolutely, I'm just 319 00:23:51,680 --> 00:23:53,400 gonna make sure include that link. It's like, look, folks, here 320 00:23:53,440 --> 00:23:57,039 it is being built up public you could and you could be a part of 321 00:23:57,039 --> 00:24:03,440 it. So they're what are you guys doing in the area of performance with 322 00:24:03,960 --> 00:24:10,200 dot net aiding with Blazer United, Are we going to enable some scenarios that 323 00:24:10,240 --> 00:24:15,160 can be more performant than done at seven? Sure, depending on how you 324 00:24:15,200 --> 00:24:21,880 look at at performance. We obviously do performance testing on pretty much everything that 325 00:24:21,880 --> 00:24:26,960 that we feield and shape, but generally in first releases you're not going to 326 00:24:27,039 --> 00:24:32,359 see us to focus a lot on performance and we focus more on on features. 327 00:24:32,799 --> 00:24:37,559 However, if you think about performance as in user metrics, you're going 328 00:24:37,599 --> 00:24:41,119 to see at enough improvement just by the fact that we are server rendering things. 329 00:24:41,279 --> 00:24:45,960 Yes, because the time to first bite, the time to interactive a 330 00:24:45,279 --> 00:24:52,880 large content paint, and all the metrics that are defined generally for measuring the 331 00:24:52,920 --> 00:24:57,200 purf of the app will all I'm expecting them all to improve, like significantly. 332 00:24:57,400 --> 00:25:02,359 Imagine just using automode right out of the box is going to architecturally give 333 00:25:02,359 --> 00:25:03,960 you better performance. Yeah, yeah, that's right. But also the streaming 334 00:25:04,000 --> 00:25:10,119 rendering feature is potentially quite a significant one for that as well. So right, 335 00:25:10,880 --> 00:25:12,480 let's talk about that after the break. We'll be right back after these 336 00:25:12,559 --> 00:25:18,440 very important messages. You know, Amazon Aws is a great home for your 337 00:25:18,480 --> 00:25:23,119 dot net applications. Whether you're looking to run your apps as serverless functions, 338 00:25:23,559 --> 00:25:30,000 have them running containers, or you require the complete flexibility of virtualized hardware, 339 00:25:30,519 --> 00:25:33,839 you can do it all on Aws. Dot Net toolkits and templates guide you 340 00:25:33,880 --> 00:25:37,960 through build and deployment, or you can use your favorite infrastructure as code and 341 00:25:38,079 --> 00:25:44,759 CICD tools including Azure DevOps, GitHub actions, and git labs. CICD. 342 00:25:45,279 --> 00:25:49,079 Loving visual Studio vs Code or Rider. There's an AWS toolkit for each of 343 00:25:49,119 --> 00:25:53,480 them. Want to use familiar Microsoft Sequel server databases, you can with the 344 00:25:53,519 --> 00:26:00,759 Amazon Relational Database service, which provides fully managed sequel server databases that for automatic 345 00:26:00,799 --> 00:26:04,759 scaling failover in snapshots. Once your dot net application is deployed, it can 346 00:26:04,839 --> 00:26:11,640 use any of the over two hundred AWS services to extend its functionality. Interested 347 00:26:11,680 --> 00:26:17,119 in AI, IoT, machine learning, video processing, or transcription. Your 348 00:26:17,160 --> 00:26:21,440 dot Net on AWS application can do it all. To learn more, go 349 00:26:21,599 --> 00:26:30,039 to AWS dot Amazon dot Com, slash net. All right, we're back. 350 00:26:30,039 --> 00:26:33,200 It's dot net Rocks. This is Carl Franklin and this is Richard Campbell, 351 00:26:33,279 --> 00:26:37,920 and we're talking to Stephen Javier about Blaze United. And you were just 352 00:26:37,000 --> 00:26:44,720 going to talk about streaming rendering, which is a new feature in Blaze United. 353 00:26:44,960 --> 00:26:48,079 Yeah, yeah, that's right. So this is part of as we 354 00:26:48,119 --> 00:26:52,880 move from a SPA centric way of thinking about why programming to one that encompasses 355 00:26:53,839 --> 00:26:59,559 traditional request responses as well, we have to find ways of retaining the same 356 00:26:59,599 --> 00:27:03,680 benefits that SPA program has had. And one of the benefits of SPA programming 357 00:27:03,839 --> 00:27:08,200 is let's say that the landing page of your site involves making a quite an 358 00:27:08,200 --> 00:27:11,839 expensive database query to get the data for like a list of dot net rocks 359 00:27:11,839 --> 00:27:15,119 episodes, and you've done like ten million by now understanding, so it takes 360 00:27:15,119 --> 00:27:19,640 a long time for that to come back. So with a SPA, traditionally, 361 00:27:21,119 --> 00:27:25,039 the user would get back some like a skeleton of HTML that doesn't really 362 00:27:25,039 --> 00:27:27,880 contain anything initially, and then it would contain some script that makes it go 363 00:27:27,960 --> 00:27:32,519 and fetch stuff from the you know, from an API and render this massive 364 00:27:32,559 --> 00:27:36,440 list, and so the UI shows up pretty quickly. Right, it's empty 365 00:27:36,480 --> 00:27:38,880 initially, but it's still there. It's better than just a spinner that's empty. 366 00:27:41,000 --> 00:27:45,000 If you move to a pure server endered mode, then what would happen 367 00:27:45,039 --> 00:27:48,240 by default if you don't do any further optimization, is that the browser does 368 00:27:48,279 --> 00:27:52,279 the HDP request to say, get me this homepage, and then you start 369 00:27:52,319 --> 00:27:55,160 doing your database query, and then you wait for like ten seconds for the 370 00:27:55,240 --> 00:27:57,920 database to reply, and the user doesn't see anything at all. The HDPU 371 00:27:59,000 --> 00:28:03,279 request is just hang open for that amount of time. Streaming rendering allows the 372 00:28:03,680 --> 00:28:08,000 server to send back the HTML straight away or like a skeleton of it, 373 00:28:08,119 --> 00:28:15,160 straight away, but keep the HTTP response open until that database query completes, 374 00:28:15,240 --> 00:28:18,920 and then it can send a further chunk of mark up which can then get 375 00:28:18,720 --> 00:28:26,640 attached to the page, so it can get merged into the dom without having 376 00:28:26,640 --> 00:28:33,200 to do any further HTP request, without having to run a full SPA programming 377 00:28:33,240 --> 00:28:37,599 and rendering system. So you get that ability of a fast initial render and 378 00:28:38,440 --> 00:28:42,759 with the ability still to patch additional data into it later. Does that make 379 00:28:42,799 --> 00:28:45,839 sense? I know it's a bit of an unfamiliar feature. So under the 380 00:28:45,839 --> 00:28:49,880 hood, is it calling? Is it using ia sync result to do your 381 00:28:49,920 --> 00:28:56,000 traditional streaming? So on the dot net side, it's just using tasks. 382 00:28:56,279 --> 00:29:02,359 So the Blazer renderer has always kept track of what pending tasks there are associated 383 00:29:02,359 --> 00:29:06,240 with a renderer. That's how the existing pre rendering system knows when to complete 384 00:29:06,279 --> 00:29:10,279 the response. So what we've changed really is instead of waiting until all those 385 00:29:10,319 --> 00:29:12,880 tasks are finished before we send the response, we now just send the response 386 00:29:12,920 --> 00:29:18,960 straight away, but we don't close the actual connection for the response until the 387 00:29:18,000 --> 00:29:22,519 tasks have completed, and at that point we do a further render and send 388 00:29:22,559 --> 00:29:26,759 a UIF to the browser. Hey, I want to go into that a 389 00:29:26,759 --> 00:29:29,480 little bit more, but I just get because this just came to my mind. 390 00:29:29,519 --> 00:29:33,960 I got to tell you, Steve, I just went through about six 391 00:29:34,079 --> 00:29:41,200 hours of absolute pain and torture trying to get bindable properties working with an observable 392 00:29:41,200 --> 00:29:45,079 collection in a maui A just to bind. And then I did the same 393 00:29:45,119 --> 00:29:48,839 thing in Blazer in about five seconds. And it just goes to show you 394 00:29:48,880 --> 00:29:55,039 the power of this binding model, of the Blazer component model, and just 395 00:29:55,119 --> 00:30:04,519 how awesome it is. I can't thank you enough for invcting. Oh my 396 00:30:04,599 --> 00:30:08,559 god. I guess the real thing is, Zammal's just still a nightmare, 397 00:30:11,799 --> 00:30:15,079 your friend. I didn't say that. I said that as a person, 398 00:30:15,359 --> 00:30:18,920 Carl, not as a Microsoft anybody. Yeah, yeah, yeah, okay, 399 00:30:19,400 --> 00:30:23,480 all right, I'm not saying Zamal your friend doesn't have emotional problems, 400 00:30:23,519 --> 00:30:29,759 your friend. It's just hard, you know, the way Zamal is all 401 00:30:29,759 --> 00:30:33,319 set up, there's just so many there's so much plumbing under the hood. 402 00:30:33,519 --> 00:30:37,200 I think it's just hard to nail. Um. But anyway, um, 403 00:30:37,279 --> 00:30:41,039 so, so this would I've been doing this kind of thing, this streaming 404 00:30:41,039 --> 00:30:47,160 rendering myself. Um, let's say, from an API that's returning a whole 405 00:30:47,160 --> 00:30:52,599 bunch of things and wrapping that AI API calling an a I a sync result, 406 00:30:53,440 --> 00:31:00,359 and then um just getting getting the data and then only you know, 407 00:31:00,440 --> 00:31:03,640 let's say that there's a thousand items in a list, but my list is 408 00:31:03,640 --> 00:31:07,200 only twenty, you know deep, so I can only show twenty at a 409 00:31:07,240 --> 00:31:11,880 time. So after first twenty, after I have the first twenty, boom, 410 00:31:11,960 --> 00:31:17,279 I call status changed. Everything rerenders and it's like instant, and so 411 00:31:17,319 --> 00:31:22,119 then every other hundred let's say, we do another render, so the list 412 00:31:22,160 --> 00:31:26,880 box sort of scroll bar starts getting wider and wider. I've been doing that, 413 00:31:26,920 --> 00:31:30,599 but it does take a little bit of work, and I think what 414 00:31:30,640 --> 00:31:33,519 I hear you saying is that you know you don't have to do the work 415 00:31:33,559 --> 00:31:41,319 now. It will It'll just stream as the data comes back and is showable, 416 00:31:41,359 --> 00:31:45,279 it'll just show. Is that what I'm hearing? Yeah, that's right. 417 00:31:45,319 --> 00:31:48,799 So we've taken the existing a data loading pattern that people already use in 418 00:31:48,839 --> 00:31:53,400 their Blazer components, and we simply made it so that you can put a 419 00:31:55,240 --> 00:31:57,119 flag. It's probably going to be an attribute I think on a component to 420 00:31:57,119 --> 00:32:00,799 say I do streaming rendering, and simply by opting into that, it means 421 00:32:00,880 --> 00:32:05,720 that the service side rendering will not wait for all those tasks to complete, 422 00:32:05,720 --> 00:32:09,400 but instead will will send each subsequent chunk of rendering down as it occurs. 423 00:32:09,680 --> 00:32:13,279 To be clear, it's not a top to bottom thing where you know, 424 00:32:13,359 --> 00:32:15,319 we send an h one element and then we don't render the next bit until 425 00:32:15,319 --> 00:32:19,720 we've got the rest of it. We do send everything in the document and 426 00:32:19,759 --> 00:32:22,759 then we can patch changes into an arbitrary locations within the document as they occur. 427 00:32:23,039 --> 00:32:28,440 So cool. Yeah, what has been the biggest challenge in designing this 428 00:32:28,759 --> 00:32:31,319 system? Oh? I don't know, Um, you got some opinions? 429 00:32:31,319 --> 00:32:35,759 Have you? Probably working with me, that's one though, Yeah, I 430 00:32:35,799 --> 00:32:45,200 would. I think I'm out that the word wave. We are both the 431 00:32:45,400 --> 00:32:51,319 very opinionated people. Yeah. Yeah, it's always fun through discustings with Steve. 432 00:32:51,640 --> 00:32:53,519 Did it start with just you guys though? Or was it was it 433 00:32:53,640 --> 00:33:00,599 stuff that was gleaned from the repose, from from the customers? What brought 434 00:33:00,599 --> 00:33:05,799 it on? So it was really a lot of like things coming from multiple 435 00:33:05,839 --> 00:33:08,799 places. There was a lot of feedback that I collected in this area over 436 00:33:08,839 --> 00:33:15,440 the years that's somewhat raised the question of of like, hey, what about 437 00:33:15,480 --> 00:33:20,799 all these other areas that were not tackling And then Steve went on a journey 438 00:33:21,000 --> 00:33:23,880 to learn more about the area and came in and said, oh, there 439 00:33:23,920 --> 00:33:29,400 are actually many great things we can do here. And then the teams started 440 00:33:29,440 --> 00:33:34,480 working together towards like creating this vision. And that's more or less how it 441 00:33:34,519 --> 00:33:37,319 happened. Steve, do you have like a magic sauna at your house where 442 00:33:37,359 --> 00:33:38,559 you go out, you know, and you just like sweat it out and 443 00:33:38,599 --> 00:33:44,039 like things come to you in a vision. And yeah, after I've made 444 00:33:44,039 --> 00:33:47,759 the relevant sacrifices and you know, vipe the right, I've solved this. 445 00:33:49,160 --> 00:33:55,680 I've solved this problem. It was hard on the chickens. Yeah, I 446 00:33:55,720 --> 00:34:01,799 mean I always thought about this issue, but I just resigned myself to the 447 00:34:01,920 --> 00:34:05,799 fact, well, you kind of have to pick your orson. You're either 448 00:34:05,960 --> 00:34:09,239 servi side or client side, and that's it. And so it's yeah, 449 00:34:09,400 --> 00:34:14,079 very interesting. We should give credit to some of the other technologies that I've 450 00:34:14,079 --> 00:34:17,079 already been doing some of this. So within the JavaScript world, there's been 451 00:34:17,679 --> 00:34:22,280 a pretty big swing over to service side rendering over the last year. And 452 00:34:22,960 --> 00:34:27,360 you know, it's not like they've all made an equal level of progress. 453 00:34:27,400 --> 00:34:30,440 Some of them have got a lot further than others. I think next JS 454 00:34:30,559 --> 00:34:34,239 is probably the one that's covered the most ground and set a lot of the 455 00:34:34,719 --> 00:34:38,440 patterns that others have tried to copy. But but you look at the server 456 00:34:38,559 --> 00:34:43,519 side toolkits for each of the different SPA frameworks, whether it's spelt Care or 457 00:34:43,559 --> 00:34:46,719 whether it's next or other things like that, you know they've all attempting to 458 00:34:46,760 --> 00:34:50,719 do stuff in this area. So you could say, in a way, 459 00:34:51,159 --> 00:34:59,119 we're simply following a trend that's occurring. There's another more sort of perhaps optimistic 460 00:34:59,199 --> 00:35:01,920 way to look at it, which is that Plaza already has certain strengths in 461 00:35:01,920 --> 00:35:06,559 this area, Like we're already got a massive head stop because we've got Blazer 462 00:35:06,599 --> 00:35:10,119 Server already, we've got one of the strongest server web offerings that there is 463 00:35:10,119 --> 00:35:15,880 available. And so this is in fact actually a very natural thing for us 464 00:35:15,920 --> 00:35:17,920 to do, to take a bit of that inspiration and then see that we 465 00:35:17,920 --> 00:35:22,239 can go further in many ways. Yeah, in Microsoft has a long history 466 00:35:22,280 --> 00:35:27,719 of server side rendering, right yep. So absolutely if you think about it, 467 00:35:27,840 --> 00:35:31,159 like in many cases, the Davastry world has gone into this journey of 468 00:35:31,280 --> 00:35:35,840 like going from the browser to the server, and we're kind of doing the 469 00:35:35,880 --> 00:35:39,159 opposite thing, which is we went from the server to the browser, and 470 00:35:39,239 --> 00:35:44,079 we're kind of both meaning in the middle for from different angles, if you 471 00:35:44,559 --> 00:35:47,440 want to think it that way. These are the healthy evolutions of an evolving 472 00:35:47,800 --> 00:35:53,320 platform space, right, we try all the things exactly. And the other 473 00:35:53,360 --> 00:35:58,719 thing that I would say is that if you go enough far backing off, 474 00:35:59,119 --> 00:36:05,119 you'll see that in the beginning s password not just an index HTML and some 475 00:36:05,280 --> 00:36:08,639 like JavaScript that loaded everything and bid requests and all that stuff. The beginning 476 00:36:08,679 --> 00:36:14,880 of office pass was really here's my JavaScript, here's my component within my page 477 00:36:14,920 --> 00:36:17,039 that was sever rendered. And that's kind of the words. Where we're going 478 00:36:17,119 --> 00:36:22,800 again is about giving people more flexibility and more granularity into how they build it 479 00:36:22,880 --> 00:36:29,519 apps. Yeah, between the magic of ajax and inner HTML, suddenly what 480 00:36:29,559 --> 00:36:31,280 do you want to do on the page? Yeah? Yes, we have 481 00:36:31,360 --> 00:36:37,599 been accused of reinventing web forms and update panel and j Query and basically everything 482 00:36:37,639 --> 00:36:42,920 else. So yeah, all the different steps along the journey, all those 483 00:36:43,000 --> 00:36:46,960 really great technologies that made it easier to develop, but implemented with the new 484 00:36:47,079 --> 00:36:52,239 understanding in the new capabilities and the richer language that we have now, Like 485 00:36:52,840 --> 00:36:55,480 these are good oscillations, and you know, to your point, and I 486 00:36:55,559 --> 00:36:59,840 grabbed links for like next JSS, Felt Kit and so forth. You know, 487 00:37:00,159 --> 00:37:04,960 alone, lots of different groups of folks that care about web development are 488 00:37:05,039 --> 00:37:09,039 experimenting with tools for exact in these exact same contexts. Yeah, that's true. 489 00:37:09,119 --> 00:37:15,880 Do you think that web assembly is getting its due respect these days? 490 00:37:15,920 --> 00:37:20,440 Are people still wary of it? Like, you know, they bring up 491 00:37:20,440 --> 00:37:24,280 the S word, you know, and non understanding that it's different than silver 492 00:37:24,400 --> 00:37:30,519 light? Do you still run into that? I would say within the Microsoft 493 00:37:30,519 --> 00:37:37,480 communities there is definitely some residual fear of the silver Light days, But honestly, 494 00:37:37,519 --> 00:37:43,639 that's a fairly small portion of the web ecosystem. Like I would imagine 495 00:37:43,639 --> 00:37:47,119 that, you know, a good eighty percent of web developers entered the industry 496 00:37:47,119 --> 00:37:52,039 after silver Light was already finished, and they don't think about that. You 497 00:37:52,079 --> 00:37:54,280 know, web assembly is not even a new technology. It's been in your 498 00:37:54,280 --> 00:37:59,679 browser since what twenty seventeen? Yeah, I think, yeah, so like 499 00:37:59,760 --> 00:38:02,480 it. It's older than probably half of the web developers careers by now. 500 00:38:02,519 --> 00:38:06,800 So I just gotta say it. You know, if you're a Microsoft developer 501 00:38:06,800 --> 00:38:10,119 and you're afraid of web assembly, just to educate yourself, it's there's nothing 502 00:38:10,119 --> 00:38:14,559 to fear here. Yeah, everybody's gonna be fine. It's a standard, 503 00:38:14,719 --> 00:38:17,280 Yeah it is. It's a standard that everybody's implement. Oh hey, how 504 00:38:17,280 --> 00:38:22,119 about that news that Safari is finally getting a makeover. I bet you're happy 505 00:38:22,119 --> 00:38:25,000 about that. Safari is getting an update that they're going to fix like one 506 00:38:25,039 --> 00:38:30,960 hundred and twenty three issues, and the issues with progressive web applications are going 507 00:38:31,039 --> 00:38:35,639 to be addressed, and notifications and all these things. All right, Yeah, 508 00:38:35,800 --> 00:38:37,280 well, I'm glad to hear that. Yeah, Safari has been a 509 00:38:37,320 --> 00:38:40,239 bit of an odd one out browser for a little while, but I've certainly 510 00:38:40,760 --> 00:38:44,960 seen they've been doing a ton of effort to try and correct that perception. 511 00:38:45,320 --> 00:38:49,199 Safari fifteen seems to be the big one, Like, this is the one 512 00:38:49,239 --> 00:38:52,719 that's going to really play well. It's going to be the one that we 513 00:38:52,760 --> 00:38:58,320 should have had ten years ago. Maybe not, yeah, alright, five 514 00:38:58,400 --> 00:39:01,079 years ago. Still error holding out for a while, all right. So 515 00:39:01,639 --> 00:39:07,440 automode basically, this is the mode you can pick for any component. You 516 00:39:07,480 --> 00:39:13,760 can pick whether it's going to be a server side rendered or web assembly rendered, 517 00:39:14,159 --> 00:39:19,039 or auto which starts as server side and then ends up as web assembly. 518 00:39:19,239 --> 00:39:22,199 Right, and you do this with word and attribute on the component. 519 00:39:22,360 --> 00:39:25,320 Yeah, that's right. Well, we're looking at different ways of specifying how 520 00:39:25,360 --> 00:39:30,400 components should render, so that the intention is that one a component can say 521 00:39:30,559 --> 00:39:34,800 its own preference about how it renders. You can have an attribute that says 522 00:39:34,840 --> 00:39:37,519 like I'm a server component, i'm web assembly, or i'm auto. Right, 523 00:39:37,159 --> 00:39:40,199 But as well as that, the person who consumes the component at the 524 00:39:40,239 --> 00:39:44,960 call site can specify what they want. So as you use a component, 525 00:39:45,039 --> 00:39:49,440 you can say render mode equals and then you can override the components own preference. 526 00:39:49,480 --> 00:39:52,960 Like, the intent is that mostly components should not express an opinion about 527 00:39:52,960 --> 00:39:55,719 how they render it. They should be agnostic, you know, they should 528 00:39:55,719 --> 00:39:59,760 be as flexible as they can to work anywhere, and then the person who 529 00:39:59,840 --> 00:40:01,440 use it will just say what they want. Yeah. So, therefore, 530 00:40:01,679 --> 00:40:07,920 your components should be completely separate from your data layer, your API layer, 531 00:40:07,920 --> 00:40:12,159 and all of that stuff should exist outside your components, except maybe in your 532 00:40:12,199 --> 00:40:15,320 pages, right, I mean they have to a page has to decide that, 533 00:40:15,440 --> 00:40:16,840 right. Well, you know that's an interesting point, right, because 534 00:40:17,679 --> 00:40:22,039 yes, and one sense, yes, all that kind of separation is all 535 00:40:22,079 --> 00:40:23,559 a good thing, but in another sense, it's all kind of overhead like, 536 00:40:23,599 --> 00:40:29,639 you're spending your time creating interfaces and abstractions and thinking about d I services 537 00:40:29,639 --> 00:40:30,960 and all that stuff, and you know, wouldn't it be better if you 538 00:40:30,960 --> 00:40:35,760 didn't have to think about any of that stuff. So we're trying to think 539 00:40:35,800 --> 00:40:44,039 about what kind of patterns around data loading or other platform specific features would enable 540 00:40:44,079 --> 00:40:45,639 people to just be more productive. And one of the key ones that we're 541 00:40:45,639 --> 00:40:52,760 looking at at the moment is multi targeting. So up to now, if 542 00:40:52,760 --> 00:40:55,639 you wanted to have something that runs on web assembly, you had to have 543 00:40:55,639 --> 00:41:00,360 a special project that compiles for website, right, But we are looking in 544 00:41:00,440 --> 00:41:06,280 dotnor eight to have a way of multi targeting your server project to say this 545 00:41:06,360 --> 00:41:09,920 is both server and web assembly, and then it will produce two separate builts, 546 00:41:10,119 --> 00:41:14,760 one for each of those environments. And then in your code you can 547 00:41:14,840 --> 00:41:17,719 have an if server or if grows or if web assembly whatever we call it. 548 00:41:19,239 --> 00:41:22,119 And so in your data loading logic you can say something like if server 549 00:41:22,559 --> 00:41:28,199 load it directly from a database with entity framework. Else call an API endpoint 550 00:41:28,280 --> 00:41:30,599 something like that, and then you don't have to bother making an interface and 551 00:41:30,840 --> 00:41:35,519 doing extra abstractions. Well, it'd be nice to use I would be using 552 00:41:35,519 --> 00:41:42,920 a repository pattern where I could implement a repository interface and then have one to 553 00:41:43,800 --> 00:41:47,920 implements my API calls, and have another one that implements my data services. 554 00:41:49,519 --> 00:41:52,119 Right, and I'm using one when I'm on the server and one when I'm 555 00:41:52,159 --> 00:41:57,119 on the client, and if that interface holds up, it should I should 556 00:41:57,119 --> 00:42:00,400 just be able to swamp them out depending on what environment. And I mean, 557 00:42:00,559 --> 00:42:02,159 right, yeah, that's absolutely one way to do it. But wouldn't 558 00:42:02,199 --> 00:42:06,039 it be nicer if you didn't even have to bother Like if you just literally 559 00:42:06,039 --> 00:42:08,679 put your data access logic in your component and you just said, if I'm 560 00:42:08,679 --> 00:42:13,960 on the server, then get it straight from the database. Otherwise call some 561 00:42:14,159 --> 00:42:15,960 endpoint. Okay, I guess it. Just you still have to do that. 562 00:42:16,039 --> 00:42:20,480 It justs depending on where you do it, I suppose. So it's 563 00:42:20,480 --> 00:42:22,599 a bit more about that, because if you think about it, when you 564 00:42:22,679 --> 00:42:27,599 like add a repository, you need to have a set of data types that 565 00:42:27,639 --> 00:42:30,039 you define that become the contract. You normally have to put those in a 566 00:42:30,159 --> 00:42:36,920 separate assembly so that both things can reference. You need to have a bit 567 00:42:37,039 --> 00:42:40,320 much more ceremony, yeah, than if you define everything on the same project. 568 00:42:40,400 --> 00:42:45,119 It gets compiled twice and at that point you don't have to add anything 569 00:42:45,119 --> 00:42:49,400 that you don't want. You want to do the repository, you can still 570 00:42:49,400 --> 00:42:52,159 do it, but you're not forced to. So your solution, Steve, 571 00:42:52,280 --> 00:42:57,440 is within this Blazer United project. Maybe instead of having in the template the 572 00:42:57,559 --> 00:43:01,199 shared folder where all your component let's go, maybe you have a you know, 573 00:43:02,800 --> 00:43:07,519 server side components and web assembly components, and you can have the same 574 00:43:08,199 --> 00:43:13,519 component in there with the same interface. It's just that depending on where they 575 00:43:13,599 --> 00:43:15,840 run, they are going to be different under the hood. Is that what 576 00:43:15,880 --> 00:43:17,920 you're saying, Well, that's one way you could do it. Yeah. 577 00:43:17,920 --> 00:43:22,599 So actually this is a very flexible system. So you could have that pivot 578 00:43:22,639 --> 00:43:24,719 on a per component basis, and we might do that with a file name 579 00:43:24,760 --> 00:43:29,599 convention. So you have my component dot server and my component dot well lovely, 580 00:43:30,119 --> 00:43:32,360 and you know it will pick the right one, but it might not. 581 00:43:32,400 --> 00:43:35,840 It could be even more granular. You could just have my component dot 582 00:43:35,920 --> 00:43:39,239 razor and inside that. Yeah, you can have a preprocessor directive that says 583 00:43:39,280 --> 00:43:43,280 this range of code is used for server and this other range for web assembly. 584 00:43:44,559 --> 00:43:46,000 Or you can have interfaces, or you can have separate projects like you 585 00:43:46,000 --> 00:43:50,920 know, whatever level obstruction is what you want, you can choose and we 586 00:43:50,960 --> 00:43:54,079 can offer that flexibility. You're just trying to offer here. If you want 587 00:43:54,119 --> 00:43:59,639 them the least amount of overhead in ceremony, use this solution. But if 588 00:43:59,639 --> 00:44:02,679 you want to have more control, you're free to implement your own. Yeah. 589 00:44:02,760 --> 00:44:05,760 Yeah, yeah, that's right. And I think there's possibly even a 590 00:44:05,800 --> 00:44:09,000 longer term vision about how data loading can be made quite opinionated. So you 591 00:44:09,000 --> 00:44:13,119 don't even think about this at all. I think I have you. You're 592 00:44:13,119 --> 00:44:15,280 starting to think about designing that you want to explain how that could work. 593 00:44:15,599 --> 00:44:22,199 Yeah, So I think one of the most where I'm trying to go for 594 00:44:22,639 --> 00:44:25,000 is to live in a world where you actually don't even have to define an 595 00:44:25,000 --> 00:44:30,079 API because you're already having all that data loading logic within your component application. 596 00:44:30,639 --> 00:44:37,199 So why would you need to have a different mechanism when you are running a 597 00:44:37,239 --> 00:44:42,239 web assembly versus when you are running on server. And one of the ideas 598 00:44:42,360 --> 00:44:49,920 is somehow translate the data that you gather on the server to the web assembly 599 00:44:50,000 --> 00:44:53,880 piece because on server, again, as we said, everything is very convenient. 600 00:44:53,960 --> 00:44:57,320 Your state and everything is on the server, you already have it. 601 00:44:57,360 --> 00:45:00,440 There is the is the breach on the client. And we already do some 602 00:45:00,519 --> 00:45:07,400 of these with pre rendering, where we actually have a mechanism that allows you 603 00:45:07,440 --> 00:45:10,360 to persist a state and will automatically pick it up on the client and applied. 604 00:45:10,960 --> 00:45:15,239 And the idea here would be that we can do that in more scenarios, 605 00:45:15,320 --> 00:45:21,199 not only during pre rendering, and that we can do that more declaratively, 606 00:45:21,440 --> 00:45:24,639 like using an attribute or something like that that you put on a piece 607 00:45:24,679 --> 00:45:28,679 of data in your component. We can handle the rest. Yeah, I 608 00:45:28,760 --> 00:45:32,239 just wanted to suggest, like as a really concrete illustration of that. You 609 00:45:32,280 --> 00:45:36,679 know, our place has got different life cycles methods today like on initialized racing 610 00:45:36,719 --> 00:45:39,239 and all that stuff. Imagine and there isn't but imagine if there was one 611 00:45:39,280 --> 00:45:44,840 called onload data racing or unloading gasing or something like that, and you put 612 00:45:44,880 --> 00:45:47,519 your data loading logic in there. But the magic of that particular one would 613 00:45:47,519 --> 00:45:52,400 be that it always runs on the server. Regardless of whether your web assembly 614 00:45:52,920 --> 00:45:57,360 or server, that particular method will always run on the server, so you 615 00:45:57,360 --> 00:46:00,880 can always talk to your database straightaway plate whatever parts of your component you want. 616 00:46:01,239 --> 00:46:06,719 I love that idea. Yeah, it just takes away an entire layer 617 00:46:06,719 --> 00:46:13,559 of your OCTASRI really wow. And and you know here's the other issue if 618 00:46:13,559 --> 00:46:16,599 you if you're going to end up in web assemily Land anyway, now you 619 00:46:16,679 --> 00:46:20,320 have to, as I said before, make an API layer. But that 620 00:46:20,360 --> 00:46:24,320 also involves data transfer objects. And you know there are tools out there to 621 00:46:24,400 --> 00:46:29,719 help you with those things. But um, have you guys thought about that 622 00:46:29,880 --> 00:46:37,000 at all? About in terms of like simplifying serialization or something simplifying Yeah, 623 00:46:37,480 --> 00:46:42,400 maybe creating DTOs from models with attributes or things like that. I don't know 624 00:46:42,440 --> 00:46:45,639 that you would need to create DTOs quite as much. Like imagine you're making 625 00:46:45,719 --> 00:46:49,679 your products editor page or something. You want to load a collection of products 626 00:46:49,760 --> 00:46:52,000 from from your database with the f or something, and then you put some 627 00:46:52,079 --> 00:46:58,840 logic on on onloading gas inc. Which populates a list of product. Well, 628 00:46:58,840 --> 00:47:00,079 that's it, Like there's no other to write that. There is no 629 00:47:00,159 --> 00:47:05,239 dto your product is the DTO in a sense like oh, you could load 630 00:47:05,320 --> 00:47:08,039 multiple things and they would all get loaded at once. I mean you can 631 00:47:08,079 --> 00:47:12,960 still freely define classes that play a DTO like role if you want, but 632 00:47:13,000 --> 00:47:15,239 you just wouldn't have to. Yeah. I suppose you're right. Yeah, 633 00:47:15,320 --> 00:47:20,960 Yeah, I think the other way to put it is that whenever you are 634 00:47:21,000 --> 00:47:24,400 serializing graphs, you need to think about like back references and things like that. 635 00:47:24,519 --> 00:47:30,119 And part of you being an engineer is figuring out that, well, 636 00:47:30,159 --> 00:47:34,000 if I don't need to like have back reference to something, maybe I can 637 00:47:34,079 --> 00:47:37,840 just live with those And as long as you keep seeing, as long as 638 00:47:37,840 --> 00:47:42,719 you keep things simple and Jason serializable, you should be good. I got 639 00:47:42,760 --> 00:47:50,039 called the task once for taking the database table architecture, representing that as a 640 00:47:50,079 --> 00:47:53,880 class and sending it down as a dto too, and then they were simple 641 00:47:53,920 --> 00:47:57,800 tables, right, you know ID, first name, last name, email, 642 00:47:57,880 --> 00:48:06,599 whatever. But the criticism was somebody can nefariously if they know that the 643 00:48:06,960 --> 00:48:10,960 that you're basically representing the shape of the data, then they can neferously inject 644 00:48:10,960 --> 00:48:16,639 things by making calls. But that seems to me that a good, good 645 00:48:16,679 --> 00:48:22,239 security is going to handle that. But I'm not sure have you ever heard 646 00:48:22,280 --> 00:48:25,039 that kind of thing before? Yeah, so NBC has that, And if 647 00:48:25,039 --> 00:48:29,480 you look at MBC, there's an attribute that is called pye never that you 648 00:48:29,480 --> 00:48:32,000 can put on a property to essentially prevent that type of attack, where like 649 00:48:32,440 --> 00:48:37,880 you're using your MTD fraenwork type and you're using an ID or a foreign gear 650 00:48:38,000 --> 00:48:42,880 or something like that. I want to prevent someone from sending up post request 651 00:48:42,920 --> 00:48:46,159 and change with that. Yeah, that's that's the way down you normally do. 652 00:48:46,360 --> 00:48:51,199 And yeah, okay, the other Yeah, the other thing is that 653 00:48:51,199 --> 00:48:54,199 you normally also use the ID from the URL or something like that has the 654 00:48:55,119 --> 00:49:00,880 input for like keen things to your database, because that's where normally do you 655 00:49:00,920 --> 00:49:06,719 have your authorization rules and everything else, and essentially avoid using the body for 656 00:49:07,440 --> 00:49:09,599 things that decide where things go. Good. Yeah, I mean, I 657 00:49:09,639 --> 00:49:13,519 suppose if you're really paranoid about it, you could create a map and you 658 00:49:13,519 --> 00:49:16,239 know, use gooids or something to send it the client and then map those 659 00:49:16,239 --> 00:49:20,079 two things in the database if you're really worried about it. But I think, 660 00:49:20,639 --> 00:49:22,760 I think there's plenty of solutions out there to prevent that from happening these 661 00:49:22,840 --> 00:49:25,679 days. In the end, I would say that it is perfectly fine to 662 00:49:25,800 --> 00:49:30,480 use videos, and it's actually what we recommend in like NBC, and we 663 00:49:30,760 --> 00:49:34,599 behind many cases because you know the exact shape of your data. We have 664 00:49:34,719 --> 00:49:37,679 attributes to make other things work. But if you can be explicit, it 665 00:49:37,880 --> 00:49:40,360 is a bit more work and a bit more ceremony. But in some cases 666 00:49:40,400 --> 00:49:44,960 it makes sense. All right, good Richard, you have any more questions, 667 00:49:45,440 --> 00:49:47,239 No, I think we've nailed this. It's of course it's still early 668 00:49:47,360 --> 00:49:51,039 days, so a lot of this we can say it's all going to be 669 00:49:51,119 --> 00:49:54,800 phenomenal because you haven't had the building yet. I guess that's right. Yeah, 670 00:49:55,119 --> 00:49:59,280 well, I can't wait for the preview coming up and coming here. 671 00:49:59,320 --> 00:50:01,679 I'm definitely to take it out for a spin in and I'll definitely talk about 672 00:50:01,679 --> 00:50:05,760 it on Blazer Train and show some demos and things. Guys, thank you 673 00:50:05,840 --> 00:50:08,280 for your continued awesomeness. There's no other way to say it. It's just 674 00:50:08,400 --> 00:50:10,880 awesome, awesome, cool, thank you. All right, Well, thank 675 00:50:10,920 --> 00:50:15,119 you for having us. You're welcome and we'll talk to you next time on 676 00:50:15,280 --> 00:50:39,559 dot net rocks. Dot net Rocks is brought to you by Franklin's Net and 677 00:50:39,719 --> 00:50:45,039 produced by Pop Studios, a full service audio, video and post production facility 678 00:50:45,360 --> 00:50:51,239 located physically in New London, Connecticut, and of course in the cloud online 679 00:50:51,280 --> 00:50:55,320 at PWOP dot com. Visit our website at d O t n et r 680 00:50:55,360 --> 00:51:00,119 O c ks dot com for RSS feeds, down modes, mobile apps, 681 00:51:00,320 --> 00:51:05,239 comments, and access to the full archives going back to show number one, 682 00:51:05,800 --> 00:51:08,599 recorded in September two thousand and two, and make sure you check out our 683 00:51:08,639 --> 00:51:13,920 sponsors. They keep us in business. Now go write some code, see 684 00:51:13,920 --> 00:51:16,000 you next time. We got a chad metal band.