How'd you like to listen to dot net rocks with no ads? Easy? Become a patron For just five dollars a month you get access to a private RSS feed where all the shows have no ADS. Twenty dollars a month will get you that and a special dot net Rocks patron mug. Sign up now at Patreon dot dot net rocks dot com. Hey Carlin, Richard Here, As you may have heard, NDC is back offering their incredible in person conferences around the world, and we'd like to tell you about them. NDC Oslow
will be me twenty first through the twenty fifth. Go to NDC Oslo dot com to register. NDC Copenhagen is happening August twenty seventh through the thirty first. Go to NDC Copenhagen dot com for more information. NDC Porto is happening October sixteenth through the twentieth. The early bird discount for DC Porto ends July twenty first. Go to Eddcporto dot com to register and check out the full lineup of conferences at DC conferences dot com. Hey, welcome back to dot
net Rocks. This is Carl Franklin and this is Richard Campbell and what it's been a Whileston. So we recorded, but we're kind of recording this right up to the wire, aren't we. I love it when we have a show the week of that. Yeah, we live the Hopper get a little low. I blame myself. I was traveling a lot. Well, you know, can't blame me for traveling. Yeah. I went down in New Zealand, Australia. Then I came home for like two days, and then I went over to Wales. So I do not know what time zone I'm
in. It's not a thing. I got back yesterday. I've got a little story for you, and that is the construction has started on my new home studio, which I'm affectionately calling Poop three point zero. Okay, that's cool. So this is in that giant garage you have, the giant garage Chat. It's a twelve hundred square foot ga and I'm taking up more than half of it with in the back and I'm gonna give it the same treatment that we did in New London in the originals, kind of Yeah, you're
gonna go right again. Oh yeah, same material and everything. Oh cool. Yeah. So they're in there now pulling out the insulation and I'm going to document it on our Facebook page. That's cool, WoT Productions. All right, enough chit chat, let's start off with Better Know framework. Well, we all know what the poly project is. If you've been listening to this show, and if you haven't used it, you really ought to check it out. Polly is a tool that you can use for resilience strategies.
So what happens when transient errors happened, your network goes down, or some network endpoint is busy or something like that. We started talking about it on dot net Rocks and then fv next became a shepherd of it. Then it got into the dot Net Foundation, and then Polly went into dot net two point one with HTTP Client Factory. So needs to say it's been a few years. There's we actually haven't had many updates to it for the past couple
of years. Well, there's also a point where it's done right, Well you'd think it's done, but there's a bit of non trivial technical debt, including lack of cancelation tokens and in some operations of a lack of file a sync support for all callbacks, and some performance issues. So what happened is the dot net team built a prototype version of Polly that simplifies Polly's API surface area with a single eye resilience strategy interface that's responsible for executing all the poly
scenarios and addresses the performance issues with excellent results. In fact, in the early test, the new changes resulted in CPU overhead reduction of eighty percent. That's nice numbers. Yeah, And additionally the proof of concept significantly reduced allocations by large factors. So these are all great optimizations. What's interesting is that
it's completely backward compatible and it hasn't happened yet. So what happens is Joel Human has written this blog post that we're going to link to, and this is eighteen thirty eight, So if you go to eighteen thirty eight pop dot me, you'll see the link. And we're looking for feedback about version eight, which is the up and coming version with all these changes. And so
that's what we want. Want you to take it for a spin, you know, check it out, and let us know you know what you like, what you don't like about it. I love me a V eight. Yes, so's it's really exciting and I hope people can jump in and contribute. Who's talking to us today, Richard, I grabbed a comment off the show seventeen ninety four. That's the one we did with jemmia Abu when we were I think we were at NDC in London. This is back in early
twenty twenty two, and of course we talked a little bit. We were talking about different front end frameworks from Vanilla JavaScript all the way through Blazer, and Josh Dabashaw had this great comedy said, I've been working almost exclusively with web components in Blazer for almost two years now, and the two work really well together. We've even gone so far as to wrap some of my web
components in Blazer components to augment them with server's side code. Fancy. Initially I went down the web component route because when the orders came from on High to use Blazer only a few months after the first release, those are early days, I wasn't convinced it was going to hold up under a load. I wanted a framework agnostic escape hatch, and I came upon the at the time new Microsoft Fast Element library. Luckily did hold up, and we've been
massively productive with our new stack. And then he goes on to say, y'all should interview Rob Eisenberg or something in a fast team. They're doing a lot of great stuff with Web and Blazer components for fluent. And by the way, Flash is not dead. Yes it is. Bite your tongue, don't believe it. You can use Flash application code to publish to canvas with an adapter library called create JS, the same syntax as action script three,
because everybody loves action script, Carl, everybody loves it. My god, I use this to make a computer based training modules at my last gig only three years ago, and it worked really, really well. I just have flashbacks to speaking of flashbacks, I have to say flashbacks. He didn't really I did. I have flashbacks to my stepdaughter in high school in the nineties talking about how her web class was all flash. They didn't even talk about HTML. It was easy, and I wanted to go down there and ring
neck guy's neck. Well, you know, people were looking for easy ways to do things. There's about it. Yeah, back at the time. So Josh, thank you so much for your comment, and a copy music Coby is on its way to you. If you'd like a copy of music, go by write a comment on the website at dot dot rocks dot com or on the Facebook's if you publish every show there, and if you comment there and I read it on the show, we'll say, do you a copy music copy and you can follow us on Twitter if you want, but
we really like you to follow us on Mastodon. I'm at Carl Franklin at tech hub dot social, and I'm rich Campbell at mastadon dot social and send us a two and check it out. Check out maskdon doesn't even matter. If it's funny, it's pretty good. Yeah, just send us the tute. Some guy just today said, hey, have you been saying send us a tute? So here it is. I'm checking out Mastodon. Thanks, thanks for the reference. Okay, let's uh bring on our guests. Steve
Sanderson doesn't need any introduction. He's he would say, yeah, I'm Steve. I'm a developer at Microsoft. But what he really is is the ventor of freaking Blazer and all other sorts of cool things and how your nelson is with him, and he's a senior software engineer on the ESPN team. Welcome, guys. I can't imagine why you came around. Hi there, Carl, Hello Richard I am glad to be back and chatting to you again. Um yet you want to say hi everyone? I'm Ahavier. I work on
Blaze on ESPN D with Steve and I'm happy to be here. Steve, how did you become so humble? Were you always this way? I think you know, I've I've practiced for many years to become as humble as I am now, and it's definitely one of the greatest accomplishments I think in human history. Astounding. It's astounding. I mean, so, were you like much more braggadocious, like in school? I was a very very quiet person at school. Yeah. Yeah, Well, anyway, that's not why you're
here. We're here to talk about what Blazer United or something like that. Yeah, yeah, so you've heard of it. What do you think so far? I have? Well, I haven't played with the bits, but everything that I see I love and I can't wait. I can't wait for the first preview. So we better tell people what the heck Placer United is? Yeah? What is it? Okay? Have you had you want to
explain the idea? Sure? So right now? When you do place or you have to choose between server and client and the idea of Place or United is essentially removing that choice that you may need to make ahead of time and enabling you to make that decision on a more granular level, not at the
level of your app, but on a per component basis. So we are trying to enhance place or with server side rendering similar to how you do NBC or recur pages, and on top of that being able to render interactive islands of functionality within your app, so that you can have as an application that starts as a server and the app that has some more modern take on server side rendering with things like a streaming rendering and that then can evolve on continue
on its path to returned activity through either server components or web assembly, and essentially trying to avoid forcing you to make a choice and letting you choose whatever fits best for your scenarios. Yeah. So the thing that catches everyone's here the most, I think is this automnode where you start as a Blazer server application and then in the background the web assembly DLLs are loading, and when
they're loaded, it switches over to a web assembly component or page. But I don't want to I don't want to glaze over the server side rendering thing, and I kind of want to talk about that and how it differs from MBC and how it differs from blazers over. Yeah, can we do a why do you care? Like? Is this about speeding up the startup time?
Yeah? It really comes down to you. So I guess one way to think about at a very high level is that we want Blazer to be suitable for all WebUI scenarios, which it isn't today, right, if we're honest, Blazer is great for certain situations, but not all of them.
Prior to dot neet a like, it's great for richly interactive sites that are so rich that it's worth downloading a dotnet runtime into someone's browser and making them wait for you know, a second or two seconds or something before before it's ready. All for scenarios which are really read and you want to run them interactively on a server, and that's cool, but that's not all of web
development. That's probably like, you know, fifty percent of web development or something, And the other fifty percent is you just want to send some HTML to people's browsers as fast as possible with the lowest possible server overhead, and it's a stateless request. Response thing, and Blazer has not been suitable for that in the past. But we are greedy and we want to eat all web UI scenarios, so we're coming for the other fifty percent. We would
like all the web please. Yeah, all right, I hear that humility kind of right, But it's not about us. It's about the customers, right. People are spending their time building their web applications and at the moment they're forced into this choice up front, like am I orienting stuff around stateless
server rendering or am I oriented and get around interactive SPA type programming. And because you have to make that choice, like have you I said, you choose once at the beginning, you're then kind of stuck with that and you
can't really cross that chasm easily. But what we've realized, and what we've seen from some other similar technologies, is that it is possible to have one UI technology that will cover both of these scenarios, so that you only have to do your work once you write your component and it can work in either this interactive mode or the stateless server mode, and then we can do all
the advanced stuff on top of that that. Have you listed a bunches of stuff where you know, we have different islands that some of them are interactors, some of an art some of a server, some web assembly, some dynamically switch from one to the other. You know, all these different advanced things. But ultimately it comes down to the fact that we want to cover all the scenarios with a single programming model, single UI technology. Is there
a case for a mixed mode? I mean it isn't ideally everything client you just as long as you don't have to wait for it. Mum. There are advantages right, well, yeah, advantages. There's advantages to both, aren't there. There's avantages to the server side, and that you don't have to hide your secrets. You don't have to have an API layer for example. Yeah, you have you have your data and your state alreadyly available on
the server. You don't have to go through all the hussle office to be client, all the things that you need to deal with like authorization, all that stuff, because it already is on the server. So it's one of the things that missus to realize me in many cases when you using Blazer server is that it's really really convenient because you have everything right at the top of
your hand. The moment you move to web assembly or do others of framework, then you have this layer where you need to be serializing everything, and as much as you can try to smooth over that, you still need to think about it. So if you have something that is highly interactive, then it makes sense for example, to be web assembly. If you are handling song operation on the server, then it might make sense for you to be able to plug an a component that that's everything on the server. So Richard's
question is really valid here in that. Okay, I see the benefit to Blazer server, but if you're going to end up that place a web assembly anyway, why would you need to start with blazers server. Well, there's a couple of advantagies. One of them is the startup time that we've alluded to. So with web assembly, you know, if the user's got a fast network connection, then hopefully the app can get started within a couple of seconds, but you know can't absolutely that, especially if they're on a slow
network connection. Whereas a Blazer server app is going to start instantly there's nothing really to download, so you've got that startup time. The other thing is all these architectural advantages that have you mentioned where you're trying to talk to your database, You can just do that right. Your code's already on the server. It can just stop to the database straightaway, no need to bother writing
API layers. It's just a very very productive environment to be in. But if it's going to eventually end up as a Websemily application in automode, you're still going to have to have the API layer and all of the things that we are required for a Websemily application, right, Oh, yeah, yeah,
you are right. Yeah. So if your intention is to have an application that genuinely works in birth modes and is able to switch between them, then you do have to be concerned about birth server side and client side concerns.
And at that point it's a pure startup time startup time optimization. Yeah, yeah, there's and it's almost a philosophical question of here is that which would consume lest bandwidth staying strictly server side and you know, interacting the client back and forth versus getting all the client down and its interacting at the API level. Because I could almost see as one of the be different commigurations based on bandwidth constraints or bandwidth cost constraints yep, yep. There's there's sons are
trade us to make. There's the bandwidth, there's the startup CPU time. There's how much time and memory you're consuming on the server. There's how much state you might need to transfer. There's the latency of UI interactions that they all put you at different points on preferring server or client side code. And we can't decide for all applications how it should be. And that's part of the goals with this new programming model is that developers can make that decision for
themselves on a very fine ground basis. It doesn't have to be the entire project is just server side, or the entire thing is web assembly. But you could have individual components where you say this one needs a superlo latency interaction like a text data to or something and something else which is just like a list of products. Maybe that's suddenly going to update once in a few minutes.
You will just run that server side, all right. Getting back to my question about the differences between server side rendering and MBC and Blazer Server, what are the differences there? Ye, So Blazer United or server side Rendering Laser is an equivalent model to MBC and racer pages in the sense that everything
is server side rendered. There is no JavaScript. The browser is the one talking to the server, and the main advantage of using racer components over NBC or race or pages is that then that component can also work on web assembly and Blazer or server and you're using a single component model or a single programming model to target all three scenarios. So the goal here as a stick mensions
is to try and reach the broader set of people possible. And pretty much nothing beats server render apps in terms of getting data to the your customer and being able to do simple interactions. So what's the difference between a Razor component in a place of server application that takes some data and some HDN splits it down and just server side rendering and place of United Yeah, so the difference is the interaction. The interaction in a place or server app happens completely on
the server. We literally delegate the event that happens in the browser and send it to the server. While in a server render app, okay, is the browser actually using the standard estemail and web technologies to serve a foreign post that then we traditionally processed like you would do in NBC or racer pages. Okay, so there's no circuit, I guess you could say, and just yeah, exactly right, that's the circuit. Happens in the circuit is the
signal our connection plus some metadata around it. They call a circuit, right, yep. Yeah, And so there's a circuit when you have a server side blaser component or page, but not when you have either web assembly obviously or server side rendering exactly and those and as we talked about this on Blazer trains to you, I was concerned about, you know, multiple circuits with multiple components, and there's only ever one circuit and it's either on or it's
not. Right, Yeah, that's right. Yeah. And the intention is that we have that circuit for the minimal amount of time that we need to so as the user navigates around, if they happen to go to a location that has a server ended component, then a circuit will start up and as soon as they navigate away from that, it can go away, which means that the amount of time that you spend holding open a connection to the server is kept as small as it kind of that reduces the costs for the web
developer, but it also gives you certain resilience benefits as well. So whenever you don't have a circuit, you don't have to worry about things like you know what if they go into a tunnel and lose their three G connection areas. So yeah, it just becomes a traditional website as soon as the circuit goes away. Back to HDB keep alive. So let's talk about that dreaded pale white reload page that happens when the circuit gets broken in a Blazer server
application. If you lose the circuit for whatever reason, the Internet goes down, or Steve said, you go through a tunnel. You know, it tries to reconnect and if it can't then you have to refresh the page or whatever. So let's say in the scenario where we have mixed things, maybe we have one page that's a server Blazer server page, another page that's server side rendered or web assembly or whatever it's you'ld only run into that issue if
you went to that page. What if you have a rendered page that has just a component, a Blazer component that's a Blazer server component on it, and you lose the circuit, does the whole page go wait? Or is it just that little component area or does it We don't know yet, right, We haven't implemented that, right, If you've got a design in mind for that, I think it's a bit of an open question. That's cool. Yeah, yeah, say so it must work perfectly an implemented yet yeah
yeah. Now you should understand and listeners should understand that we are at an early stage of design right now. We've got a good prototype and we did some cool demo videos, but the real implementation we've only just got started on in the last month, and there's tons of open questions and we are looking
for a lot of feedback on many aspects of the design. People can follow along and get up and see the work as it goes in with prs, and we often write things in the PR description which is like open question what should happen and blah blah blah, And it's great when people come along and
give us their feedback on that. And that thing that you've just raised there is exactly the sort of thing that we still are you know, design is pending on that, right, and you're targeting the dot net eight timeframes, so November of twenty twenty three, that's right, Yeah, yeah, And I say targeting genuinely say like some features will make it as some features will not, Like software is complicated and it's a preview out yet or no.
The first preview that you're going to see something of this is Dotnet eight preview three. I don't know the release state, but we've just gone through the CD complete point for that at the end of last week, so it's probably a month away or something. I don't know have yet. Do you know in it ships, it's just another pretty regular cavens. I don't have the exact day, but every month. I used to be more worried about done previews, but I'm not anymore because I know it's ships every month. They're
like clockwork. Yeah yeah, yeah. You stop having that pressure to get everything done for a given release. You know there's just another release coming. Better make it right. I said, to make the deadline you really want to get it like in previous seven rather than But yes, I didn't have
the cojones to actually do the nightly build and try it out. Yeah No, I wouldn't really recommend most people to bother trying to get the prototype code runningcause you do have to build the whole ESPNT Core repo and yeah, it's not that easy, to be honest with you, but yeah, hopefully it's only a few weeks away until some of the first parts of server rendering show up. It'll be fairly basic in the first prev three that we won't have
streaming rendering or even the ability to put interactive components on the page. But you'll start seeing some of the core APIs come together and this is being built in the asp net core gethub repository, Like, that's where that's where I see the issues, Like, that's where folks should be going if they want to participate. That's absolutely right, Yeah, yeah, absolutely, I'm just
gonna make sure include that link. It's like, look, folks, here it is being built up public you could and you could be a part of it. So they're what are you guys doing in the area of performance with dot net aiding with Blazer United, Are we going to enable some scenarios that can be more performant than done at seven? Sure, depending on how you
look at at performance. We obviously do performance testing on pretty much everything that that we feield and shape, but generally in first releases you're not going to see us to focus a lot on performance and we focus more on on features. However, if you think about performance as in user metrics, you're going to see at enough improvement just by the fact that we are server rendering things.
Yes, because the time to first bite, the time to interactive a large content paint, and all the metrics that are defined generally for measuring the purf of the app will all I'm expecting them all to improve, like significantly. Imagine just using automode right out of the box is going to architecturally give you better performance. Yeah, yeah, that's right. But also the streaming rendering feature is potentially quite a significant one for that as well. So right,
let's talk about that after the break. We'll be right back after these very important messages. You know, Amazon Aws is a great home for your dot net applications. Whether you're looking to run your apps as serverless functions, have them running containers, or you require the complete flexibility of virtualized hardware, you can do it all on Aws. Dot Net toolkits and templates guide you through build and deployment, or you can use your favorite infrastructure as code and
CICD tools including Azure DevOps, GitHub actions, and git labs. CICD. Loving visual Studio vs Code or Rider. There's an AWS toolkit for each of them. Want to use familiar Microsoft Sequel server databases, you can with the Amazon Relational Database service, which provides fully managed sequel server databases that for automatic scaling failover in snapshots. Once your dot net application is deployed, it can use any of the over two hundred AWS services to extend its functionality. Interested
in AI, IoT, machine learning, video processing, or transcription. Your dot Net on AWS application can do it all. To learn more, go to AWS dot Amazon dot Com, slash net. All right, we're back. It's dot net Rocks. This is Carl Franklin and this is Richard Campbell, and we're talking to Stephen Javier about Blaze United. And you were just going to talk about streaming rendering, which is a new feature in Blaze United.
Yeah, yeah, that's right. So this is part of as we move from a SPA centric way of thinking about why programming to one that encompasses traditional request responses as well, we have to find ways of retaining the same
benefits that SPA program has had. And one of the benefits of SPA programming is let's say that the landing page of your site involves making a quite an expensive database query to get the data for like a list of dot net rocks episodes, and you've done like ten million by now understanding, so it takes
a long time for that to come back. So with a SPA, traditionally, the user would get back some like a skeleton of HTML that doesn't really contain anything initially, and then it would contain some script that makes it go and fetch stuff from the you know, from an API and render this massive list, and so the UI shows up pretty quickly. Right, it's empty initially, but it's still there. It's better than just a spinner that's empty.
If you move to a pure server endered mode, then what would happen by default if you don't do any further optimization, is that the browser does the HDP request to say, get me this homepage, and then you start doing your database query, and then you wait for like ten seconds for the database to reply, and the user doesn't see anything at all. The HDPU
request is just hang open for that amount of time. Streaming rendering allows the server to send back the HTML straight away or like a skeleton of it, straight away, but keep the HTTP response open until that database query completes, and then it can send a further chunk of mark up which can then get attached to the page, so it can get merged into the dom without having to do any further HTP request, without having to run a full SPA programming
and rendering system. So you get that ability of a fast initial render and with the ability still to patch additional data into it later. Does that make sense? I know it's a bit of an unfamiliar feature. So under the hood, is it calling? Is it using ia sync result to do your traditional streaming? So on the dot net side, it's just using tasks. So the Blazer renderer has always kept track of what pending tasks there are associated
with a renderer. That's how the existing pre rendering system knows when to complete the response. So what we've changed really is instead of waiting until all those tasks are finished before we send the response, we now just send the response straight away, but we don't close the actual connection for the response until the tasks have completed, and at that point we do a further render and send
a UIF to the browser. Hey, I want to go into that a little bit more, but I just get because this just came to my mind. I got to tell you, Steve, I just went through about six hours of absolute pain and torture trying to get bindable properties working with an observable collection in a maui A just to bind. And then I did the same thing in Blazer in about five seconds. And it just goes to show you the power of this binding model, of the Blazer component model, and just
how awesome it is. I can't thank you enough for invcting. Oh my god. I guess the real thing is, Zammal's just still a nightmare, your friend. I didn't say that. I said that as a person, Carl, not as a Microsoft anybody. Yeah, yeah, yeah, okay, all right, I'm not saying Zamal your friend doesn't have emotional problems, your friend. It's just hard, you know, the way Zamal is all set up, there's just so many there's so much plumbing under the hood.
I think it's just hard to nail. Um. But anyway, um, so, so this would I've been doing this kind of thing, this streaming rendering myself. Um, let's say, from an API that's returning a whole bunch of things and wrapping that AI API calling an a I a sync result, and then um just getting getting the data and then only you know, let's say that there's a thousand items in a list, but my list is only twenty, you know deep, so I can only show twenty at a
time. So after first twenty, after I have the first twenty, boom, I call status changed. Everything rerenders and it's like instant, and so then every other hundred let's say, we do another render, so the list box sort of scroll bar starts getting wider and wider. I've been doing that, but it does take a little bit of work, and I think what I hear you saying is that you know you don't have to do the work now. It will It'll just stream as the data comes back and is showable,
it'll just show. Is that what I'm hearing? Yeah, that's right. So we've taken the existing a data loading pattern that people already use in their Blazer components, and we simply made it so that you can put a
flag. It's probably going to be an attribute I think on a component to say I do streaming rendering, and simply by opting into that, it means that the service side rendering will not wait for all those tasks to complete, but instead will will send each subsequent chunk of rendering down as it occurs.
To be clear, it's not a top to bottom thing where you know, we send an h one element and then we don't render the next bit until we've got the rest of it. We do send everything in the document and then we can patch changes into an arbitrary locations within the document as they occur. So cool. Yeah, what has been the biggest challenge in designing this system? Oh? I don't know, Um, you got some opinions? Have you? Probably working with me, that's one though, Yeah, I
would. I think I'm out that the word wave. We are both the very opinionated people. Yeah. Yeah, it's always fun through discustings with Steve. Did it start with just you guys though? Or was it was it stuff that was gleaned from the repose, from from the customers? What brought it on? So it was really a lot of like things coming from multiple
places. There was a lot of feedback that I collected in this area over the years that's somewhat raised the question of of like, hey, what about all these other areas that were not tackling And then Steve went on a journey to learn more about the area and came in and said, oh, there are actually many great things we can do here. And then the teams started working together towards like creating this vision. And that's more or less how it
happened. Steve, do you have like a magic sauna at your house where you go out, you know, and you just like sweat it out and like things come to you in a vision. And yeah, after I've made the relevant sacrifices and you know, vipe the right, I've solved this. I've solved this problem. It was hard on the chickens. Yeah, I mean I always thought about this issue, but I just resigned myself to the fact, well, you kind of have to pick your orson. You're either
servi side or client side, and that's it. And so it's yeah, very interesting. We should give credit to some of the other technologies that I've already been doing some of this. So within the JavaScript world, there's been a pretty big swing over to service side rendering over the last year. And you know, it's not like they've all made an equal level of progress.
Some of them have got a lot further than others. I think next JS is probably the one that's covered the most ground and set a lot of the patterns that others have tried to copy. But but you look at the server side toolkits for each of the different SPA frameworks, whether it's spelt Care or whether it's next or other things like that, you know they've all attempting to do stuff in this area. So you could say, in a way,
we're simply following a trend that's occurring. There's another more sort of perhaps optimistic way to look at it, which is that Plaza already has certain strengths in this area, Like we're already got a massive head stop because we've got Blazer Server already, we've got one of the strongest server web offerings that there is available. And so this is in fact actually a very natural thing for us to do, to take a bit of that inspiration and then see that we
can go further in many ways. Yeah, in Microsoft has a long history of server side rendering, right yep. So absolutely if you think about it, like in many cases, the Davastry world has gone into this journey of like going from the browser to the server, and we're kind of doing the opposite thing, which is we went from the server to the browser, and we're kind of both meaning in the middle for from different angles, if you want to think it that way. These are the healthy evolutions of an evolving
platform space, right, we try all the things exactly. And the other thing that I would say is that if you go enough far backing off, you'll see that in the beginning s password not just an index HTML and some like JavaScript that loaded everything and bid requests and all that stuff. The beginning of office pass was really here's my JavaScript, here's my component within my page
that was sever rendered. And that's kind of the words. Where we're going again is about giving people more flexibility and more granularity into how they build it apps. Yeah, between the magic of ajax and inner HTML, suddenly what do you want to do on the page? Yeah? Yes, we have been accused of reinventing web forms and update panel and j Query and basically everything
else. So yeah, all the different steps along the journey, all those really great technologies that made it easier to develop, but implemented with the new understanding in the new capabilities and the richer language that we have now, Like these are good oscillations, and you know, to your point, and I grabbed links for like next JSS, Felt Kit and so forth. You know, alone, lots of different groups of folks that care about web development are
experimenting with tools for exact in these exact same contexts. Yeah, that's true. Do you think that web assembly is getting its due respect these days? Are people still wary of it? Like, you know, they bring up the S word, you know, and non understanding that it's different than silver light? Do you still run into that? I would say within the Microsoft communities there is definitely some residual fear of the silver Light days, But honestly,
that's a fairly small portion of the web ecosystem. Like I would imagine that, you know, a good eighty percent of web developers entered the industry after silver Light was already finished, and they don't think about that. You know, web assembly is not even a new technology. It's been in your browser since what twenty seventeen? Yeah, I think, yeah, so like it. It's older than probably half of the web developers careers by now.
So I just gotta say it. You know, if you're a Microsoft developer and you're afraid of web assembly, just to educate yourself, it's there's nothing to fear here. Yeah, everybody's gonna be fine. It's a standard, Yeah it is. It's a standard that everybody's implement. Oh hey, how about that news that Safari is finally getting a makeover. I bet you're happy
about that. Safari is getting an update that they're going to fix like one hundred and twenty three issues, and the issues with progressive web applications are going to be addressed, and notifications and all these things. All right, Yeah, well, I'm glad to hear that. Yeah, Safari has been a bit of an odd one out browser for a little while, but I've certainly seen they've been doing a ton of effort to try and correct that perception. Safari fifteen seems to be the big one, Like, this is the one
that's going to really play well. It's going to be the one that we should have had ten years ago. Maybe not, yeah, alright, five years ago. Still error holding out for a while, all right. So automode basically, this is the mode you can pick for any component. You can pick whether it's going to be a server side rendered or web assembly rendered, or auto which starts as server side and then ends up as web assembly. Right, and you do this with word and attribute on the component.
Yeah, that's right. Well, we're looking at different ways of specifying how components should render, so that the intention is that one a component can say its own preference about how it renders. You can have an attribute that says like I'm a server component, i'm web assembly, or i'm auto. Right, But as well as that, the person who consumes the component at the
call site can specify what they want. So as you use a component, you can say render mode equals and then you can override the components own preference. Like, the intent is that mostly components should not express an opinion about how they render it. They should be agnostic, you know, they should be as flexible as they can to work anywhere, and then the person who
use it will just say what they want. Yeah. So, therefore, your components should be completely separate from your data layer, your API layer, and all of that stuff should exist outside your components, except maybe in your pages, right, I mean they have to a page has to decide that,
right. Well, you know that's an interesting point, right, because yes, and one sense, yes, all that kind of separation is all a good thing, but in another sense, it's all kind of overhead like, you're spending your time creating interfaces and abstractions and thinking about d I services and all that stuff, and you know, wouldn't it be better if you
didn't have to think about any of that stuff. So we're trying to think about what kind of patterns around data loading or other platform specific features would enable people to just be more productive. And one of the key ones that we're
looking at at the moment is multi targeting. So up to now, if you wanted to have something that runs on web assembly, you had to have a special project that compiles for website, right, But we are looking in dotnor eight to have a way of multi targeting your server project to say this is both server and web assembly, and then it will produce two separate builts, one for each of those environments. And then in your code you can have an if server or if grows or if web assembly whatever we call it.
And so in your data loading logic you can say something like if server load it directly from a database with entity framework. Else call an API endpoint something like that, and then you don't have to bother making an interface and doing extra abstractions. Well, it'd be nice to use I would be using a repository pattern where I could implement a repository interface and then have one to implements my API calls, and have another one that implements my data services.
Right, and I'm using one when I'm on the server and one when I'm on the client, and if that interface holds up, it should I should just be able to swamp them out depending on what environment. And I mean, right, yeah, that's absolutely one way to do it. But wouldn't it be nicer if you didn't even have to bother Like if you just literally put your data access logic in your component and you just said, if I'm on the server, then get it straight from the database. Otherwise call some
endpoint. Okay, I guess it. Just you still have to do that. It justs depending on where you do it, I suppose. So it's a bit more about that, because if you think about it, when you like add a repository, you need to have a set of data types that you define that become the contract. You normally have to put those in a separate assembly so that both things can reference. You need to have a bit much more ceremony, yeah, than if you define everything on the same project.
It gets compiled twice and at that point you don't have to add anything that you don't want. You want to do the repository, you can still do it, but you're not forced to. So your solution, Steve, is within this Blazer United project. Maybe instead of having in the template the shared folder where all your component let's go, maybe you have a you know, server side components and web assembly components, and you can have the same
component in there with the same interface. It's just that depending on where they run, they are going to be different under the hood. Is that what you're saying, Well, that's one way you could do it. Yeah. So actually this is a very flexible system. So you could have that pivot on a per component basis, and we might do that with a file name convention. So you have my component dot server and my component dot well lovely, and you know it will pick the right one, but it might not.
It could be even more granular. You could just have my component dot razor and inside that. Yeah, you can have a preprocessor directive that says this range of code is used for server and this other range for web assembly. Or you can have interfaces, or you can have separate projects like you know, whatever level obstruction is what you want, you can choose and we can offer that flexibility. You're just trying to offer here. If you want
them the least amount of overhead in ceremony, use this solution. But if you want to have more control, you're free to implement your own. Yeah. Yeah, yeah, that's right. And I think there's possibly even a longer term vision about how data loading can be made quite opinionated. So you don't even think about this at all. I think I have you. You're starting to think about designing that you want to explain how that could work.
Yeah, So I think one of the most where I'm trying to go for is to live in a world where you actually don't even have to define an API because you're already having all that data loading logic within your component application. So why would you need to have a different mechanism when you are running a
web assembly versus when you are running on server. And one of the ideas is somehow translate the data that you gather on the server to the web assembly piece because on server, again, as we said, everything is very convenient. Your state and everything is on the server, you already have it.
There is the is the breach on the client. And we already do some of these with pre rendering, where we actually have a mechanism that allows you to persist a state and will automatically pick it up on the client and applied. And the idea here would be that we can do that in more scenarios, not only during pre rendering, and that we can do that more declaratively, like using an attribute or something like that that you put on a piece of data in your component. We can handle the rest. Yeah, I
just wanted to suggest, like as a really concrete illustration of that. You know, our place has got different life cycles methods today like on initialized racing and all that stuff. Imagine and there isn't but imagine if there was one called onload data racing or unloading gasing or something like that, and you put your data loading logic in there. But the magic of that particular one would
be that it always runs on the server. Regardless of whether your web assembly or server, that particular method will always run on the server, so you can always talk to your database straightaway plate whatever parts of your component you want. I love that idea. Yeah, it just takes away an entire layer of your OCTASRI really wow. And and you know here's the other issue if you if you're going to end up in web assemily Land anyway, now you have to, as I said before, make an API layer. But that
also involves data transfer objects. And you know there are tools out there to help you with those things. But um, have you guys thought about that at all? About in terms of like simplifying serialization or something simplifying Yeah, maybe creating DTOs from models with attributes or things like that. I don't know that you would need to create DTOs quite as much. Like imagine you're making
your products editor page or something. You want to load a collection of products from from your database with the f or something, and then you put some logic on on onloading gas inc. Which populates a list of product. Well, that's it, Like there's no other to write that. There is no dto your product is the DTO in a sense like oh, you could load multiple things and they would all get loaded at once. I mean you can still freely define classes that play a DTO like role if you want, but
you just wouldn't have to. Yeah. I suppose you're right. Yeah, Yeah, I think the other way to put it is that whenever you are serializing graphs, you need to think about like back references and things like that. And part of you being an engineer is figuring out that, well, if I don't need to like have back reference to something, maybe I can just live with those And as long as you keep seeing, as long as
you keep things simple and Jason serializable, you should be good. I got called the task once for taking the database table architecture, representing that as a class and sending it down as a dto too, and then they were simple tables, right, you know ID, first name, last name, email, whatever. But the criticism was somebody can nefariously if they know that the that you're basically representing the shape of the data, then they can neferously inject
things by making calls. But that seems to me that a good, good security is going to handle that. But I'm not sure have you ever heard that kind of thing before? Yeah, so NBC has that, And if you look at MBC, there's an attribute that is called pye never that you can put on a property to essentially prevent that type of attack, where like you're using your MTD fraenwork type and you're using an ID or a foreign gear or something like that. I want to prevent someone from sending up post request
and change with that. Yeah, that's that's the way down you normally do. And yeah, okay, the other Yeah, the other thing is that you normally also use the ID from the URL or something like that has the input for like keen things to your database, because that's where normally do you have your authorization rules and everything else, and essentially avoid using the body for
things that decide where things go. Good. Yeah, I mean, I suppose if you're really paranoid about it, you could create a map and you know, use gooids or something to send it the client and then map those two things in the database if you're really worried about it. But I think, I think there's plenty of solutions out there to prevent that from happening these days. In the end, I would say that it is perfectly fine to use videos, and it's actually what we recommend in like NBC, and we
behind many cases because you know the exact shape of your data. We have attributes to make other things work. But if you can be explicit, it is a bit more work and a bit more ceremony. But in some cases it makes sense. All right, good Richard, you have any more questions, No, I think we've nailed this. It's of course it's still early days, so a lot of this we can say it's all going to be
phenomenal because you haven't had the building yet. I guess that's right. Yeah, well, I can't wait for the preview coming up and coming here. I'm definitely to take it out for a spin in and I'll definitely talk about it on Blazer Train and show some demos and things. Guys, thank you for your continued awesomeness. There's no other way to say it. It's just awesome, awesome, cool, thank you. All right, Well, thank you for having us. You're welcome and we'll talk to you next time on
dot net rocks. Dot net Rocks is brought to you by Franklin's Net and produced by Pop Studios, a full service audio, video and post production facility located physically in New London, Connecticut, and of course in the cloud online at PWOP dot com. Visit our website at d O t n et r O c ks dot com for RSS feeds, down modes, mobile apps, comments, and access to the full archives going back to show number one, recorded in September two thousand and two, and make sure you check out our
sponsors. They keep us in business. Now go write some code, see you next time. We got a chad metal band.