Daniel Roth is the Product Manager at Microsoft for Blazor. They delve into the world of .NET, focusing on the latest updates for Blazor and the upcoming .NET 9 release. With detailed discussions on server reconnection, form handling, and rendering in dotnet 9, they explore the intricacies of Blazor's interactivity and the evolution of the framework since its inception. The episode also features valuable insights on improving user experiences, leveraging AI in app development, and the upcoming changes in authentication and identity endpoints. Stay tuned as they unravel the innovations and advancements in the .NET ecosystem and beyond. 

Hello, and welcome to another episode of adventures in dot net. I'm Sean Claver, your host. And with me today, we've got everybody, the full panel. We all managed to to match up. Must be because it's, Easter weekend that here was recording.

So we've got Christian Wentz. Hi, everyone. Mark Miller. Hey, kids. Adam Vermontek.

Hello, Fox. Yep. And me. And we have a guest. We have a guest that's that's been here before.

He's been here twice before, but it's actually been 3 whole years since he's been on the show, Daniel Roth. Hey, Daniel. Hello. Hi, everyone. It's great to be back.

It's been too long. It has. I don't know why we waited so long because I love every one of your episodes, and they're very popular. So we need to not wait 3 years for the next one. Sounds good to me.

That's good. So what have you been up to? Well, I'm still working on dot net and, building, awesome web apps using the the the the dot net platform. It's not too long ago, just back in November that we shipped dot net 8 with a whole bunch of stuff for for Blazor. I'm I'm still working on Blazor as our premier WebUI framework for building web applications, with with dot net.

It was a pretty big release for for for Blazor. So that was a lot of work. I don't know if that had anything to do with me not coming on the podcast. Things were pretty busy, honestly, as we were trying to cram as many features into this release as we as we could to deliver the, you know, really the the vision that we were trying to to get to with dot net 8, which is having a single solution, a single way for you to build your your web UI part of your of your web applications for no matter what type of of web architecture you you you want it, whether you wanna do server side rendering or client side rendering or really anything in between. So is Blazor use been growing and growing as it should have been?

It has been growing. Yes. We're very happy with the, the growth of the, blazer, platform. And it's it's fun also just to talk to, to, to customers and see, hear the things that people, do with it. I think one of the areas that blazer is really, resonates with with people is, when you when you're trying to do, like like, more but with with less.

Right? Like, if you're if you're a large organization and you already have a a well established, like, front end JavaScript team, you know, those those orgs you know, they they if they have a back end dot net, they they find Blazor interesting, but, you know, they have, you know, existing patterns and and set up there. The existing investments that they're already, set up with. But people that are like, I I wanna build something. I need to be fast.

I need to be agile. I need to be productive, and I don't have the luxury of spinning up an entire separate team using an entirely different developer framework and platform. Blazor is just such a, you know, wonderful thing for them. I've I've talking to to teams even internally at Microsoft, that that are using Blazor for various line of business applications, and these tend to be, you know, small, tight teams, but need to, you know, have that level of agility. They are just super happy with the the the the productivity that they get out of Blazor.

So why don't you give us a brief, you know, run over of the way Blazor was prior to dotnet8? And then we can get into what's changed and why it's why it's better now. Yeah. Sure. So, I mean, Blazer's, you know, come a long way.

Like, it's not a it's not a new framework anymore. I know sometimes people still say, oh, you know, Blazer, we're gonna wait and see if it's, you know, if it's gonna stick around or I you know, what what direction is Microsoft's gonna go with Blazer. We should When was when was the first version? Was it 3 dot one core time frame or something? It was 20, 2019.

Like, it's, like, 5 5 years old, the the first stable release. Even before that, I mean, the the very first that where the Blazer name came from was, is actually a a prototype that Steve Sanderson did in 2017 at, an NBC Oslo conference, I think is what it was. He was trying to show us some, you know, things that browsers could do at that time that, were very new, like WebAssembly was was a brand new technology at that time, and, he was playing around with it. And he thought, oh, wouldn't it be cool if I could get a little bit of dot net code compiled to WebAssembly somehow and be able to run that in a in a browser? You know, took a little little tiny dot net runtime, got it compiled to WebAssembly, did hello world in a browser.

And, of course, this is Steve Sanderson that that we're talking about. He's a, architect on the ASP dot NET team. Him him being Steve, he was he then decided, well, what if I then took that and and built a little web framework? And that's that's where Blazor originally came from, a lot of DOM diffing based, component based rendering framework. That's what he built for this.

It was just a demo, and then he also did, like, a bunch of tooling work for it. Like, he got all the the razor editor in Visual Studio to to work with it, which was just mind boggling that he did this as just a a a demo prototype. So that that was 2017, and, we then you know, there was, lots of interest, but lots of questions about how viable this was going to be as a as an approach. And so we spent a fair amount of time, running Blazer as well as an experimental release. Like, you know, no commitment that this would actually turn to a stable release yet, but we wanted to learn and hear from the community about how how desirable was this.

And we also wanted to learn internally how practical was it for us to actually build it because the dot net web assembly runtime didn't really exist yet. The one that Steve built was a total, like, you know, one off. I think he found some c code on GitHub where someone had built a little dotnetil interpreter, and he compiled that to WebAssembly. But it wasn't something we could really rely on for production use. And so getting that all, sorted out took some time.

That, the experimental part of Blazor started in earnest in about, early 2018. And then we shipped, in 2019 with dot net core 3 dot o, actually, like, which was the first official Blazor release that had the Blazor component model in it as a, you know, supported part of the dot net platform. That's when we introduced Blazor Server, which is the interactive server rendering, notion. If you're you're you're still trying to really mimic client side rendering, like what you would do with client side JavaScript, but we we did it remotely from the server over a real time connection with the browser, over a WebSocket connection. And that was really Kinda like ASP dot NET Web Forms on steroids.

Right? Is that what you're saying? Or, like, I I mean, I ASP, Web Forms was still a, traditional for the most part, traditional server side steroid. Framework. You know, request.

Done right. Yeah. They did have, though, this this one control in called update panel, which I know a lot of people squint at Blazor server and kinda say, it has some some similarities to the old update panel from from the web forms days. That bought us you know, got us into the the world of being able to do rich interactivity with dot net. You know?

Button click, drag and drop, whatever, you know, any UI inter interactions you wanted to handle, you could now do using dotnet code. We then had the support for running truly on the client in a browser with WebAssembly in, mid 2020. I think it was when we shipped Laser WebAssembly for the first time, and that rolled into the dot net 5 release later that that year. And, you know, lots of stuff has happened since then, but the big shift in dot net 8 is that Blazer was originally envisioned as a way to fill that gap in the dotnet platform. Like, if I wanna do client rendering, you know, rich interactivity without having to, you know, to jump into JavaScript, how can I do that?

And that's that's what Blazor really, helped with. In dotnet8, it has now expanded to be a complete end to end web UI framework for doing not only client side rendering, but also, traditional service, static server side rendering where you you get a request. You then route that to a blazer component. You render HTML that goes down to client, and that that interaction is stateless. It's, it's, fast.

It's it's very easy to scale. Blazor now supports that traditional style of static server side rendering in dominate. And on top of that, we added a whole bunch of them progressive enhancements. Like, you can just start adding a little bit of of client side logic to improve the user experience, like, doing enhanced navigation. When when you do a page navigation from one page to another, instead of that being an entire, it's it's still a separate request.

But instead of blowing away everything that's in the DOM and then reestablishing everything again, when a lot of it's, you know, gonna be the same often when you're just not getting pages, enhanced navigation will do a a fetch request to get the rendered HTML from the server. And then Blazor uses its, you know, you know, fancy Dom diffing capabilities to then patch that into the Dom so that the the page navigation feels smoother. It feels it's it's faster. It feels less disruptive. It's more like a single page app navigation, than what you would normally get from from traditional static server side rendering.

Streaming rendering was another progressive enhancement, like, when you when you navigate to a page and you need to render that page, but you need to go get some some data from a database or make an API call. In traditional static server side rendering, you'd have to wait for the that that data to be retrieved before you got anything back in the browser. Streaming rendering allows you to, you know, send some HTML down with some placeholder content and then stream batches of updates that Blazor can then, again, patch into the DOM for you as the data becomes available. So maybe you see, like, a loading dot dot dot initially when the data from the database is now available. You patch into the DOM the you know, your grid or whatever it is you're using to display that that that data.

That that's also great for for sorry interrupting, Daniel. That's I think it's also great for for progress bars. Right? So basically, in in in your server, quote unquote, implementation, you just, you know, set set the progress bar to another state, and then that state appears on the client. Right?

While still the server is working. Right? So that's Using, like, using a streaming rendering pattern when you're, like, stream updates on progress. Yeah. Absolutely.

You could you could do that. Yep. That works. And the but the beautiful thing is is that, in addition to just doing the the the, you know, old what's honestly a fairly old pattern. Right?

Like, static server side rendering has been around forever, but web forms sort of did this, and older frameworks and web forms have been doing that for for a long time. But then you can because it's all Blazor components, you can then add interactivity to that app wherever you need it. Like, you could light up a single component on a page and say, you know what? This component needs to be interactive, and you can choose how you want it to be interactive. You want it to use the the in interactive server model, the Blazor server model where it's gonna be handled from the server over a WebSocket connection.

That's super convenient. Or or if you wanna actually push that interactivity to the client, you can flag that component and say, you know what? You need to to run client side on on web assembly. You can do that on a per component, granularity, on a per page granularity or for the whole app, which would get you to something that's very, similar to what you had with, like, Blazor web assembly or or Blazor server. So which features that are coming to Blazor you're most excited about?

So that well, I mean, that was all done today. So that's that's that's there, and I'm excited about all of that. That's the full stack web UI support that we ship with with dotnet8, and you can use it today. It's in the long term support release, so you will be supported for 3 plus, 3 plus years, which is great. Of course, now we're in a new year.

We're already, looking at the what's what's next for Blazor, looking forward to the the dot net 9 release, which is the the next release of the platform that, if you're familiar with our release cadence, it's expected to ship in, November of, of this year, of of of 20 24. So the the dot net 9 is kinda interesting for Blazor because we we we shipped so much in in dotnet8. Like, it was a packed release, and a lot of it, like, even came in fairly late. Like, we were pushing in features even, like, in the release candidates, which is not something I we normally would recommend, but we were really trying to round out that vision where you could, you know no matter what type of web UI you want, you could build it with with Blazor. It's now our recommended solution for for web UI development with dot net.

There are definitely things that, you know, some gaps, rough edges, you know, things that we didn't quite get enough time to to hone in in dot net 8 that we are focusing in dot net 9 on addressing, addressing gaps in the the new Blazor web app, model. For example, performance is a big part of everything we do in dot net. Like, we care deeply about making sure you get as much throughput out of your and and server utilization out of your server resources as as possible. We didn't really get enough time in dotnet to do all the performance optimization on the new static server side rendering support in Blazor that, that we wanna do. Like, it's still it's still very fast.

Like, it still benefits from all the performance characteristics of the dot net platform, but we know we can can do more. There's a bit of a gap right now in laser static server side rendering and, like, traditional NBC or razor page based based rendering. And so we wanna close that gap and make it, you know, as as as close as we can to the, the old models. The old models are will always be a little bit faster than Blazor static server side rendering because they they don't do quite as much. Like, they're, like, an MVC view is a, you know, stream based model just viewing HTML directly out, whereas Blazer has the the component model in in play.

So there's a little bit of overhead with, the that comes with getting all the nice features that comes with Blazer's component model, but it shouldn't be big. And right now, it's a little too big for for our liking. So we're gonna, do a bunch of performance work to to to optimize that. We're gonna do just a bunch of things to just make sure that all the Blazor web app features work smoothly and flawlessly together. We right now have a good model for going from static service side rendering to interactivity.

Like, if you start with static page and you wanna add some inter interactivity in it, that works great. We've got a we've got a good pattern for doing that using the new Blazer render modes. We don't have a good way of going the the other direction. Like, if you take your app and say, you know what? I want everything in this app to be interactive, like an old school blazer server app.

But except for this page, this one page here, I would like that one to be static because it doesn't really need the interactivity. We don't have a good way of doing that. There there's there's ways to do it, but they're kind of, you know, clunky. So we wanna make that a more first class notion in in dotnet9, both for, you know, rendering pages and also when doing, like, form handling. Like, we introduced full traditional form handling in in in Blazor in in dot net 8.

If you want to, have the form be interactive, but you want the submit to to be handled using a normal form submit. We don't have a way to to make that shift from interactivity to, to to static style, web app development. So we're gonna add that in dotnet9. I know a lot of people who are building components would like to be able to inspect at runtime what the current render mode is. Like, is this component rendering statically, or is it rendering laser server style, or is it on web assembly?

I would like to know. And you can kinda work it out with some, I don't know, say, hacks, but, like, by piecing it together from from various APIs. But we're we think that we could do better in video a first class API for deducing those things. So you can build components that do things like, light up functionality based off of their current render mode. Like, maybe if you're rendering statically, you want to render certain DOM elements.

But when you're doing it interactively, you actually wanna change that up because you can do more. You can make things more virtually interactive. Like, having that ability to to to decode that logic into your components, that's something we're also, we're looking to do in in the dot net 9 time frame. So, you know, a bunch of things in that that bucket of, like, you know, little gaps, little rough edges in the Blazor web app model. We wanna smooth that all out, make sure it works really nice and cleanly.

Like, in general, I would say for dot and 9, our focus is on fundamentals and and quality and less less transformative. Like, dot and 8 was a very transformative release. You know, we moved to shuffle things around quite a bit, and people are still, I think, working through that. Okay. How do I how do I move my app forward?

How do I migrate from the old dot net 8 patterns to the new dot net 9 patterns? The idea of dot net 9 is we're not we're not gonna be moving your cheese nearly as much. We're instead we're gonna take the things that we've already shipped and try to just make them better, faster, stronger. So high level, that's that's a that's a good way to think about what we're doing in the dotnet9 time frame. Doesn't mean we're not doing new features too.

We have a bunch of new features as well, but, it's more about volume fundamentals this time around. I I got a quick question or or terminology clarification. So when you when you say interactivity with Blazor, especially to those who don't work with Blazor, you essentially mean client events plus Yes. Streaming rendering? Is that is that kinda, a sound definition of of the term?

Exact exactly what we mean. Soon as you have one of those two features or one of these two aspects in your app, then that that's the that's the, interactivity setting in the in the dotnetclire and the Visual Studio, create new Blazer web app wizard. That's that's basically the thing. Yep. Yep.

You you you mentioned an interesting point with the, what what what what do you do with, with old applications. Right? So let let's imagine you started with dotnet6 or even earlier. Dotnet.net3.0, with Blazer server. Right?

And you have a great running Blazer server app. And then maybe, you know, you change the program CS style between dot dot 5 and dot dot 6. Right? So you thought you you thought, okay. Now now you are on on safe ground.

Right? And now you see the new template. There is no Blazer server template. No no no dedicated Blazer server template that that in the name. So what should you do?

So Should you just leave it as it is? I mean, it's still working. Right? Yeah. So we I mean, obviously, we care deeply about back and back in the dominant platform.

You should be able to we we wanna make sure you can move your app forward from version to version, and things should just continue to work. So existing Blazor server apps and Blazor Web Assembly apps, you can just change the target framework to dot net 8. You can update your packages to the dot net 8 versions, and that should just work. That is still fully supported. It's not that the Blazor server or Blazor WebAssembly models have gone away.

They they are both still there, and you can run those those that style of app on dot 8 in a fully supported mode. So that's the easiest way to upgrade your app is just leave it at as it is and update the to to dominate. No no no problem. You then have the option of also migrating your app to use the new Blazor web app patterns, the new Blazor web app features. And that will then the the benefit of doing that is that then enables you to use things like the interactive render modes where you want them, then the, your your, your components become proper endpoints in the ASP dot NET Core routing system.

There's a bunch of benefits that you get out of moving to the to the new model. And we provide a migration guide that shows you how you can move from one to the other while maintaining exactly the same semantics. You can yeah. You mentioned that the Blazor server template, no longer exists in dot NET 8, and that's true by by name. But the the the pattern of Blazor server is absolutely still there.

You can take a Blazor web app, and you can say, I would like this Blazor web app to use interactive server rendering. You know, use a WebSocket connection for all the, you know, client side events globally for the entire application. And that is the same thing as what you had with a Blazor server app. So you you you there's some changes in the code in terms of how we accomplish that now. Like, you need to use the new Blazor web script instead of Blazor dot dot server dotjs, use Blazor dot web dotjs.

You no longer need to have razor pages or CSHTML in the picture to accomplish this. We we because we can now statically render components from from the server, the root rendering of the app can now just be a a dotrazor file, like a component file. So we can use app dotrazor instead of, you know, what was it, like, underscore host dot cshtml or whatever it was in the in the old template. So you can move from 1 to to the to the other. There's a set of fairly mechanical changes that you make to for particularly for blazer blazer server applications, similar deal for blazer web assembly apps, particularly the ASEMET core hosted blazer web assembly app.

That was a, you know, Blazer code that would be pushed client side and run-in the browser. But the thing that hosted those files, server side, was an ASP NET core process. So it was ASP NET core hosted. You can have that same pattern with the Blazer web app. There's a couple of different changes that you need to to make in your existing base made core hosted Blazor WebAssembly app to to to use the new patterns, but you can do it as well.

The the one of the big changes that I think people often get tripped up on in that world is that we started in dotnet8, prerendering, Blazor WebAssembly apps by default. And what is prerendering? Prerendering is where when you make the initial request, you know, most of the with the Blazor WebAssembly app, most of the code's gonna run client side in the browser. That's where all the rendering's gonna happen. That's where all the UI events are gonna be dealt with.

But with that initial request, well, we could just go ahead and render the components up front, like, give you a batch of HTML so you can get pixels on the screen immediately. With Blazor Server, that was a no brainer. Might as well do that. Your your your components are gonna run from the server regardless. With Blazor WebAssembly, we didn't used to do it because it adds some complexity.

Like, that means your components are now gonna run on both sides of the network that run the server and on the client, and you have to think about that when you're building your app. Like, you you actually need might need different services injected depending on where your components are running. Like, if that component needs some data while on the server, it can get it directly from the database. From the client, it might need to do an API call. You know, these types of concerns.

So when you're migrating, you many people didn't do prerendering previously, so they, you might our guidance is generally to to turn off prerendering when you're when you're moving to the Blazor Web App model, if you're if you're moving a a Blazor Web Assembly based app because your components probably weren't set up for that. If your components were, then you're then it's actually just enabled for you, and you the work that you used to have to do manually to set up prerendering, you no longer have to do. That's that's one of the the common gotchas with migration. But, otherwise, the the steps are fairly straightforward, and we have, detailed docs that walk you through how to do this in the, case management core migration doc set. Were there any other changes to the template that are maybe a bit more subtle and not related to the to the new model?

Like, I don't know, how navigation is done or different different colors. Okay. That's a stupid example. But but but you know where I'm getting. Right?

So so where where there any other things that are that are noteworthy? So navigation definitely is different, like, by default. If you just create a Blazor web app, we, by default, turn on interactivity just for the counter page, which is this, you know, page that has a button you click on and the count goes up. It's showing how you can handle a button click event. The other two pages that are in the sample code for a Blazor web app, the the home page and there's, like, a weather forecast page that shows a table of weather forecast data.

Previously, all those pages would have been, interactive, and they would be, handled using client side routing where Blaze is just intercepting the browser navigations and then, you know, doing, manipulating the DOM directly. In the by default, in the new template, we're using normal ASP dot NET core routing. You you send a request to the home page. It gets sent to the server. There's an endpoint there.

It renders the home page. You get HTML content back. Then if you browse to the weather page, that's another endpoint. It makes another HP request to the weather page. It gets the weather data back.

Now there's some some, refinements to what it will do. It will do an enhanced navigation. Like, it won't do a full navigation. So Blazor will intercept the navigate the the browser navigation, but it it won't do the rendering over, like, a WebSocket connection or on WebAssembly. It'll still let the server generate the HTML.

It'll just patch it into the DOM, from whatever it gets on the response stream. The weather page also is is, different in a significant way in that it's using streaming rendering to generate the weather table. Previously Loading loading text. Yeah. So you'll see loading dot dot dot, and then you'll see the weather table show up.

Now in all earlier versions of the template, you would have seen loading dot dot dot, and then the day data show up as well. It looked, from a user experience, very similar. But what it was doing under the covers is very different. Like, in a Blazor WebAssembly app, it would actually have, like, an HP client, and it would call an API endpoint. And the reason why you saw loading dot dot dot is because that's what it rendered while it was waiting for that client HP request to complete.

So, you know, get get get the JSON payload, deserialize it, and then render some h, an HTML table based on whatever it got. With, streaming rendering, it works differently. There's no API endpoint that you're actually interacting with. The the data is really all being handled server side, at least mimicked as if it's being handled on server side. It's actually just being generated in memory.

But we can think of it as being a server side API call or being a server side database query. So you get you see loading dot dot dot, which is the initial batch of HTML that goes down to the the browser, but the connection stays open. And then once the, weather data is ready and we we even put, like, a fake delay in the code to show you that this is happening, to simulate, like, an actual asynchronous API call or or database break, then a little bit later, you get the component renders again with the with the actual weather data, and that gets patched into the the DOM. So I I think a bunch of people have been, thrown off a little bit by that because they're like, wait a minute. How do I do the API call thing now?

And and in this case, the answer is actually, well, you don't really need to. Like, the server can just handle that for you by doing, streaming rendering, and then you don't have to mess around with having an API endpoint that you have to design and secure and all those those those those concerns. So that part is also a a a little bit different. There's not a, in the template, not an API call there anymore. But but we do have docs and guidance, though, that because there are obviously cases where you might wanna make a client API call back to the server on how you can still, set that up and do it.

It's it's the same thing. You still inject an HP client and just use it, but, it's no longer just in the template code. Has there been any changes in the state management and things like that? Because I remember early days, if you did server side and you redeployed the server code or whatever, everybody would get this message. Code has changed or whatever.

You must reload your page and, you know, to start it up again. So Yeah. That's that's, specific to the, the with interactive server rendering. So with you know, interactive server rendering is a a very unique Blazor feature. Like, I don't I don't think really any other web framework has this pattern.

I mean, I think it may be one that's, Phoenix or something has something kinda similar to what we do. But most of the other popular front end JavaScript frameworks don't do this. It's really convenient because your code's all running on the server and it's stateful, right? Like you have, you can have state just sticking around on the server as you're interacting with the the user. You can talk to your database directly because you're already on the server.

So it's very convenient and productive for for building, an app. But the problem is it's also stateful. So if that state goes away for any reason, then the user can end up in a poor experience. Like like you said, if the server gets restarted, any state that you had just sitting around in memory for that Blazor server app or interactive server rendering based Blazor web app, there's nothing in Blazor that will persist that for you or try to rehydrate it. So if the server restarts, the user will see a disconnect.

Right? Because it's also a connected model. You require that active WebSocket connection with the server in order for the UI to function. So the the the app will notice, hey, there's no longer a connection to the server. And it will let the user know and say, hey.

I'm no longer responsive. I'm trying to reconnect to the server. Let me see if I can get back again. Like, maybe it was just a transient network connection. You went through a tunnel or whatever.

But if if it wasn't just a transient connection, the when when the, browser re is able to finally reconnect again to the server when it restarts, it will ask the server, okay, reconnect me back to this particular it's called a circuit, like the state that I was previously associated with. And the server will say, I don't have it anymore because it's it's it's gone. And now the the framework will then tell the user, like, hey. I'm sorry. I I I was able to reconnect, but I couldn't reconnect back to your state.

And so the only thing you can really really do at this point is refresh the browser and and start again. And this is a known, you know, pain point with Blazor server based based apps. If you're if you have, you know, anything that happens server side to that, that circuit state can result in this new user experience. So one of the things we're actually looking to do in point 9 is is to improve that reconnection logic. We're like, there are a bunch of problems with it today.

Like, the reconnection is kinda slow. It only will try to reconnect, like, every 20 seconds. So the user even if the the servers come back up pretty quick, the user might sit there in that broken state for up to 20 seconds. That's not great. So we're gonna reduce that.

Who came up with the 8 retries? I mean, these are these are so odd, well, Ethan, but still, you know, we we are not the number. Seconds, I get. But we try 1 out of 8, 2 out of 8, I I I'm always confused. I always Yeah.

You know, default values are a funny thing. Right? Sometimes they're a bit like throwing darts at a dartboard, our best guess. And sometimes there's more principles that go behind them. You know, this I think this is a case where we shipped it.

We shipped the reconnection experience that we currently have. And we have been learning from user feedback that there are there are cases where it's problematic. Of course, you can configure all these things. Like, you can configure what the the retry duration is. You can retry configure how many times it retries.

There's also how long the server will hold on to the circuit state when, when the client connection is lost. Like, one one thing that often happens is, like, people will put a browser tab into the background. Like, you know, like swipe the browser away on your phone, for example. And on most platforms, that will actually close the WebSocket connection. Okay.

So the server sees the connection is gone. And then it's like, well, I've got this circuit state here. Should I hold on to it? By default, Blazor server will. It will will hold on to it for a period of time.

I think it's fairly short, like 3 minutes. But you don't generally wanna hold on to it forever because then that becomes a potential, you know, DOS vector where people just keep creating connections and closing them. And now you've got all these circuits that are sticking around. You need to clean them up. So if the user has swiped away for longer than 3 minutes and then comes back to the app, they might have that situation again where they connect to the server, try to get back to their circuit, and the circuit's no longer there.

The server didn't restart. It just decided to get rid of the circuit because you you you went away for for for too long. So we're gonna try and improve this this this this set of reconnection experiences. The the the UI that we actually show is is not particularly great. And we're gonna try and refine that, make it a little bit nicer.

We're gonna shorten the reconnection period. We'll start auto refreshing the browser for you. So you don't like, you can write that code today where it just automatically does the browser refresh for the user instead of just showing the user an error. We're gonna start just doing that by default because that's pretty much what everyone wants anyway. And we're also gonna try, and do some client state persistence.

Like if the user was in the middle of a form and typed a bunch of stuff, we'll try to at least save that and re reestablish it again into the form so that it's not lost. The one piece that we're not doing in Donnet 9, which I'm, you know, a little sad about that I really wanna get to is is helping facilitate saving the server state. Like, if you were if you had clicked the counter a bunch of times, let's say, and the count says, you know, 32 or whatever, and you're really proud that you clicked the counter 32 times, but then you swipe away and then come back and the circuit is gone, nothing will save the fact the counter had 32 clicks on it. You can write application code to to do that. And we have some samples that show you some patterns that you can write in your app to, you know, persist data at a particular moment and then rehydrate it again when the the, a new circuit gets created.

But it's a bit tedious. And there's some timing issues. Like, we don't have all the right events that we really need, the APIs in order to hook in and actually be able to persist state at all the appropriate moments. That work is still pending. And it's not gonna make it in for for for dotnet9, we think.

It's probably gonna be, you know, again dot, dotnet no. Post dotnet9. I'm not gonna commit to a particular release, but, that's the one part that I think people will still have to to deal with in their own code is, like, persisting server side state. So maybe like the old ASP dot NET, you know, store state and SQL Server or some other, you know, server for the state versus the application server code is on 1 and states on another? Yeah.

So it's it's a similar, like, like, session state type of if you wanna have state that survives across, requests in old, you know, traditional static server side rendering based applications, you needed a store to put that thing in or you put in the cookie. Right? You need some place to put it so that you can hang on to it. It is similar and and analogous in in in nature. It's not it's not quite the same problem, but it has similar characteristics.

So so are you looking in server side storage, or are you maybe also leveraging, I don't know, local storage? I mean, especially when using the server in active mode, you can have the protected local storage. So, yeah, there might be a way, but, of course, it only works so far as long as, you're using that model. Right? There's also It's a bit better than you stated.

It's a a cross site scripting of where you stated. That's Yeah. We're definitely not going to, we're not gonna try and, like, persist everything about the the state of the components for you. Like, there's not gonna be a view state was kind of magical. Right?

Like, if, like, web forms would try to just do this, like, save everything. Save everything. And then you would get into cases where people put too much stuff in there and get enormous and it caused problems. The plan is that it will still be an explicit developer decision, how much you want to save. We're just gonna give you the API so that you can do that, exactly where you store it, you know, like Redis or database.

Like, there's lots of options there. And there's always been like a like a plug in type of model where you you you tell us where you want us to save things, and we maybe have some, recommended places that are more convenient that you can just just use. Whether you can store things on the client, like, you know, put service move the service state to the client, as you mentioned, there's there's there's limitations for for when you'd actually be able to do that. Are there any changes that are specific to affecting, like, Blazor Hybrid or Blazor Desktop, whatever you wanna call it? Yeah.

Also, the I mean, the main thing for Blazor Hybrid that we're gonna do is try and give you a template so that if you want to build for web, mobile, and desktop, that you don't have to piece that together manually. Like, this is one of the beautiful things about Blazor Hybrid. Blazor Hybrid is, for people that don't know, that's that's a way you can take your existing Blazor components, the same ones you would use in your web app, and you can embed them into a native client app and render them to, like, a local web view control and use them as the UI layer for a native application, native desktop, native mobile. We have Blazor Hybrid support for dotnet MAUI, so all the platforms that dotnet MAUI supports. We also have, Blazor hybrid support for WPF and, and WinForms, so you can build, you know, native Windows desktop apps using, this this pattern.

And so you can today set it up yourself. You can create a a Blazor web app, and you can create a Blazor Hybrid app and then have, like, a common shared library of components that you use for both of them so that you have one set of components for your UI, and you can then multitarget all the platforms that are that are interesting. But it's very manual. In Donna and I, we're gonna try and give you a a free can template that will just do set that all up for you. There's some particular complexities that got introduced also with the with the render modes in Blazor web apps that, that we're also going to address.

If you have a component right now that, has been attributed to say, I I need to run on web assembly, and then you try to use that component in Blazor Hybrid. Well, Blazor Hybrid will say, this component says it needs to run on web assembly, and I'm not running it on web assembly, so it will throw. We're gonna do some work to relax some of those constraints, make that easier, and also give some guidance and samples on how you can still do this with even with dot and 8, with the, dot and 8 implementation of the render modes. So that's the big thing there. There's I know there's also just general, investment happening for, like, desktop scenarios in dotnet Maui, improvements to the, the WebView controls, like WebView 2.

And, I know there's some issues with, like, drag and drop today with Blazor Hybrid and, and and Maui on Windows because of some issues with the WebView 2 control that the the WinUI team is working on. And there's also a lot of, like, just docs and guidance work that's happening in the Blazor Hybrid space, to make it easier for you to to to build your native client apps using web technologies. I'm interested to know, if there are any upcoming features or upcoming visions that are secret that you know about that you're really excited about that you can't talk about. You know, I think everything that I would if I were to list all the things I'm excited about, they're all I think they're all public and most I think they're all open source that, that I'm aware of. So, like like, dotnet, Aspire, and the cloud native work that that's happening.

Like, that's super cool. Like, being able to build, orchestrated, containerized cloud native apps using dotnet in just a really easy way. A lot of the work around AI, of course, is, like, super hot and amazing. We just shipped a bunch of samples how to do, use the, you know, the OpenAI services with with dotnet. And and, actually, even more recently, we, we just provided a set of experimental Blazor and, MVC, controls, like UI controls for doing AI things at the UI layer, like doing smart paste and smart, text areas and smart combo boxes.

These are, controls and components that that allow you to add AI powered functionality to your app without having to know, like, everything about large language models and RAG and prompt engineering and all the all this stuff, which is, you know, fun and interesting. But if you're just trying to get the job done, it can be a bit overwhelming. We've now have a bunch of controls you can just drop into an existing app and get some pretty, pretty amazing functionality. Like, the the SmartPaste, if you haven't seen the the video, I strongly encourage you to go check out Steve Sanderson's, YouTube demo for this where, like, imagine you have, like, an address form where you need to, you know, put in all the fields, all the, you know, the street and city and ZIP code and all that stuff. And you're trying to put that in based off of some text that someone sent you in an email.

So smart paste will allow you just, like, you copy the the text, and you just click a smart paste button. And then we use the OpenAI services to correctly parse the text that you gave us and put the right data in each of the right fields semantically. Another cool demo he shows that's similar is, like, imagine you're trying to submit a bug report, and you got the bug report in an email from, like, one of your users, and it's all in text. He shows just he just copies the basically, the email text, smart paste into a, you know, bug report form, like the the GitHub, issue tracker UI or whatever, and it puts in all the right fields. And the severity markings and the repro steps are all nicely formatted.

It's just pretty amazing what the OpenAI stuff can do. The text area is like smart completions or suggestions. Like, if you have, you know, forms that users are using that, like, HR answering questions from from from employees or, like, a call center where they have fairly standardized answers that they need to give. The, smart text area gives you a a free canned way of having really intelligent suggestions as you're, like, typing to help you quickly type out those things. Semantic search.

These are all just a set of pre canned, AI powered UI controls that you can just use today. So definitely check that out. There's a re it's a it's a public, repo with sample code. And if you find them interesting, they are currently experimental because we're trying to learn here, like, which smart controls would actually smart components would actually be useful and what do people actually wanna do with them. There's a survey link in the smart components repo and in the blog post.

I would love it if you would, would take and let us know what you think about the that that controls that. So those those are all and they're and they're they're public. They're not secret. Everything we're doing in dotnet9 is again, it's open source. It's public.

It's not secret, and we invite you. You know, come come come help us out. Come come join us in the in the fun. I I didn't get a chance to talk about the WebAssembly investments. So I do wanna make sure I mentioned those because we are doing some new things in WebAssembly.

The, the big one is is, we're trying to get multithreading going in in Blazor in in dot net 9. If you've been following Blazor, this has been a quite a journey. Like, we've been working on this for for years, honestly. But the runtime work is is is in in good shape. The the the the getting the runtime to actually support, initiating new multiple threads and having it run-in a separate worker thread so that we don't block the the main UI thread.

The big work items that's still remaining there is, to get Blazor when it's running on WebAssembly to not make any single threaded assumptions. That's a big chunk of work. So I I don't know that we'll actually land it as a, par as a stable supported feature in dotnet9, but I'm hoping it'll at least be available for you to to use and and and and and and try out. We've had it available for at the lower level, like where you could write some, like, very low level dot net code and use multi threading. We've never gotten it fully functioning in the blazer environment yet.

That's where we're trying to get to in the the dot net 9 timeframe. Yeah. My take on it is that, Daniel's hiding secrets behind things he's really excited about. That's what I think. He's excited about other stuff.

He just hasn't told you yet. Well, you know, I I to be completely transparent and honest, like, I I work primarily in the public open source sphere. So, almost everything that I work on is is is not not secret. I'm happy I'm happy to talk about it. Like, it's No.

I think, seriously, I I think it speaks to the cadence. Doesn't it? I think it really speaks to the cadence at which things are coming out in the manner in which they're coming out, the open source manner. And the development philosophy. Like like, pretty much everything I I I do.

We the code is available for you to look at, to inspect, to, to clone and build yourself, to to con contributions to. Like, it's a very community centric way of doing software development. And that's that's a key part of what we do in the the the dot net world. Like.net is an open source community driven, platform. So, yeah, there shouldn't be any secrets.

Like, you know, dotnet platform is, is owned by, in some sense, by by all of us. So can I can I ask a specific, planning question maybe? So, in in in Docker date, one of the new features for Blazor was in terms of authentication with the updates to the template using, using ice bin that identical identity, And I think also the new identity API endpoints, right, slash register slash login. Now I remember that those new endpoints, they were marked as experimental when dot net 8 came out. So, like, might be subject to change.

So what's coming in dotnet9? Will that stay the same? Will will Blazer change something in terms of authentication? What's what are the plans there? I mean, dotnet9 is 7 and a half months probably away.

Right? So, yeah, it's probably also a matter of time. So in dotnet8, there was a ton of work that went into improving the authentication story with the ASM four. We moved away from we moved more to, like, a back end for front end pattern for a lot of our authentication flows. Previously, we were using, more like a token acquisition and OIDC directly from different clients in order to handle that.

We ended up moving away from that from that for various reasons. Much, much better. Yes. So that that's that's all still in place, and then we'll continue to to exist. We also introduced the, laser identity components.

Previously, when you were using ASP dot NET Core identity for handle authentication within your own app, we gave you, like, a default UI for doing login and logout and external logins and, two factor auth and all those types of things. And it was all built with razor pages. And if you're a Blazor user, this this caused some some friction. Like, people didn't like the fact they were having to mix these 2 different UI frameworks in the same app. So in dotnet, in dotnet8, we introduced a set of Blazor components as part of the templates that, implement the same UI functionality.

In Visual Studio, there is actually now a, a a scaffolder, a new Blazor identity scaffolder that we've introduced that you can use to add the Blazor identity components to an existing, ASP dot NET Core app or Blazor app to get the those components included in your app without having to to file new projects. So that's that's also there. I know we also have work there's work still in progress on our, Microsoft Entra support. Entra's in if you Entra's the new brand for the Azure Active Directory or Azure Active Directory via b b to c, you know, the organizational based, account authentication. We didn't get the option in the Blazor web app template in dotnet8 for turning on, like, Microsoft identity platform based authentication or intra based auth, in the the the template.

So we're working to get that template work done so you have tooling to help you, set up that style of authentication and also samples and guidance so that you can do it today with your existing, dot net based based applications. So that's also coming as well as the, tooling in Visual Studio for adding Microsoft Intra based authentication into an existing app. Similar to, like, scaffolding, but, I think it's done through the ad connected services based based flow. The identity endpoints question is interesting. I actually had I I don't I didn't think that they had been marked as, I thought it was mentioned when when it was released, but, sorry if I should be wrong.

But, let me just double check. I'm gonna ping someone. Yeah. Let's on the fly. Let me double check.

But but, really, it sounded like yeah. That's so so they are new, and maybe they changed, maybe they won't. But, again Well, I understand. I may I may have this wrong. I that's not it's not exactly my my area.

I do work closely with this. I thought the new, identity endpoints, the programmatic ways of interacting with ASP for identity that they had actually shipped and and and dominate and were supported. Check me on that if I'm wrong, but I believe they they were. And that's useful for things like where you do need to have a token based flow, like, if you have a, like, a NetDawn and Maui, based client and you want to get a, you know, tokens that you can call some some API endpoints, those identity endpoints are are are useful for that still. So I think they are available.

And, yeah, they they will continue to to exist. But I'll double check on that, and we can, you know, take those questions off. Yeah. Yeah. So so I sorry.

Sorry if I should spread the misinformation. But I think it it I I don't remember the exact wording, but it was like, okay. Early work. Give us your feedback. Stuff like that.

So maybe that early work meant the API endpoints are fixed, but that's not the end of the line, and there will be more becoming. I I I'm not sure about that. But I was I was just wondering. Right? Because, again, it was it was late as early work or something.

Right? So I was just wondering, will will I need to update my code? But, sounds like I don't have to sure. With with with with with. Exactly.

I mean, as as you as you just said at at at the beginning, right, that that's that's the max of credo of, of having this backwards compatibility. I was I was reading the the tweet by, I think, Dave Dave Plummer last week when he told the story how he built that format disk Windows UI, you know, these if you format, you know, a thumb drive or something or even your hard drive, that that formatting UI in Windows. He built that 3rd years ago. So now if you have Windows 11, try to format a thumb drive, it will look exactly the same. And he kind of explains how he built this again 30 plus years ago and still hasn't changed, still working.

It's a bit different with Blazor. Right? So that that did evolve quite a bit from from being a conference demo in 2017 to now being a fully fledged framework that's still innovating. Yeah. Well, I mean, the front end web development space moves very fast.

Like, the the innovation is is, moves at a break next next speed. And we understand that like, like, we've been talking about back compatibility. Like, one of the things we try very hard actually across the dominant platform and in Blazor is to make sure that you can upgrade from version to version without having a lot of a lot of pain. And we like, I know in a lot of the front end world, we're moving from with other frameworks, this this can be a big problem. Like, I'm moving from one major version to another and I end up having to do a lot of, code changes to to to upgrade.

We want that to never that should never be the case at this point with, with with Blazor application. You can adopt the framework and feel comfortable that you should be able to move it forward, fairly seamlessly and take advantage of new dotnet platform features without having to, like, rewrite your app. I mean, the Blazor web app stuff is a is is a something you opt into. Like, you can choose to to to migrate to those to those features, but you don't have to. Like, there's not if you're happy with your Blazor server app today, there's no requirement to turn that into a, like, you know, interactive server rendering based, based web app.

I did I was just checking on the, the release notes documentation that we have for dot net 8, and the identity API endpoints absolutely are are there. So they are part of the, the the shipped and supported functionality in in in dominiti. Okay. So they'll they'll stay the same for the foreseeable future. Okay.

That's that's fantastic to you. So the the early work basically meant, okay, there might be more more to come apart from register, log in, and log out? Yeah. There might be more more functionality that they plan to add. I mean, we we can just, augment the existing, end endpoints.

Although even that, I'm not I'm not familiar with any, significant things that are happening in the dotnet9 time frame to add to the identity endpoints. But again, not not not strictly speaking my area, so this might be something I'm just not familiar with. You can always find out by, looking into GitHub repo and seeing what the devs are working on because like I said, none of it's secret. It's all it's all right there. So before we, wrap up and move on to PIX, can I have AI write my Blazor app for me so I can just do more with less?

You can do quite you can do quite a bit. Like, you can use GitHub Copilot in Visual Studio and ask it to do things for you, and it will absolutely write a lot of your code. It's pretty it's pretty good. It's pretty, amazing, actually, how much it can, figure out about what what your intent is. I mean, it's not gonna not gonna be perfect.

So make sure you check code, read it over. You know, don't just blindly copy and paste, but you can actually get a lot out of the GitHub Copilot functionality. I know David Fowler has done some really fun demos where he shows like David Fowler is an architect on the dotnet team. And he is a very active proponent of using GitHub Copilot gig. And he uses it, tons in his own development efforts working on dotnet Aspire and working on the the the framework.

So if if that's any inspiration, like, it is it is real. Like, it's not it's not just hype. Like, the the the productivity gains from using GitHub Copilot are pretty pretty striking. Okay. So anything that we haven't covered that you wanted us stick in here before we move on to VIX?

I'll also make one more mention on WebAssembly, which is on the we know that one of the downsides of dot net on WebAssembly is the the load time of the app. Right? Like, people were concerned about the size of the download, how long that takes, and then getting the app to actually, load up. We are doing a bunch of work in in dotnet92 to speed that up. It's not so much in the past, we've we've focused on reducing the size, like how much how small can we shrink this thing?

You know, we use compression and trimming and all these tricks to try and get the dot net run time and the core dot net libraries as as small as possible. In dot net 8, we did some actually some some, cool trickery where we, we could try to hide the download time of the Blazor WebAssembly app by using this auto render mode where you start an interactive component using the interactive server model, which is you know, just requires a WebSocket connection, while you sneak down the Blazor WebAssembly runtime in the background. And then on subsequent renders, when the WebAssembly runtime isn't available, then it switches over to use true client side rendering. So you get a fast initial load while also being able to move the burden of operating that code to the client. In dot net 9, we're gonna do some optimizations around how those files get retrieved, like how the static web assets get handled.

Today, there's kind of a cascade of requests that that happen as part of loading up that Blazor WebAssembly app. We're gonna be doing things at build time to, optimize how that load happens. So we can add, like, link tags and start using pre preloading techniques so that those requests can all just sort of happen in in in parallel. We're going to do more with, precompression. Precompression has a build time optimization we do where we take your web assets and run broadly compression on them really aggressively so that they're already compressed and ready to go once your app is deployed.

That feature right now is limited to, you know, some Blazor WebAssembly specific files. In dotnet9, that will expand to more of the assets that are being downloaded. Like, you can pre compress your JavaScript files, your CSS files, and so forth and get that that added benefit. We're doing some, you know, more modern bundling techniques with our own, Blazor framework files like Blazor.web.js, like making that file smaller. Just optimizing how the static web assets come down.

And then also the once you have everything downloaded, getting the dotnet runtime started actually is takes a little bit of time. Like, getting it running. Like, you know, you say WebAssembly code start start running. Like, from there to when you actually have your dotnet code executing fully and handling events has a little bit of delay, we're working to reduce that startup time, even further, both the Blazor initialization code and also the startup time of the the dotnet runtime itself. So the idea is that, hopefully, the the total time from, you know, when you hit the page, get all the files downloaded, get them cached, get the runtime up and up and going, that that total load time will be as as fast as possible.

So a bunch of work happening in the, in the load time optimization space as well. Could it throw the runtime into local storage so it only has to get it the first time or if there's any changes? We so we already do that. We don't we don't put in local we put in the, the cache. We use the caching APIs to store those files locally.

And, in fact, one of the optimizations that that we'll we're gonna do in dotnet9 is we're gonna start fingerprinting every single static asset so that it has a unique cache that's that's generated from its content in the file name. And then we'll use, other browser caching techniques in dotnet9 to tell the browser, like, hey. You got this once. Don't ever download it again. We'll use we'll we'll generate e tags based off of that same hash as well.

So if you can't use, like, the immutable browser caching, you can still fall back to the e tag behavior. So that that actually basically already exists at .net. Where you once you've downloaded it, downloaded it once. You don't need to download it again. So it's really just first load that, Blazor WebAssembly apps are are heavily impacted by.

But even that first load, we care about. So that's that's why we're doing all these other optimizations in dotnet9. Got it. Cool. Yeah.

And I think local storage wouldn't work because there are size limitations, and it's a string API, essentially. Right? So that wouldn't be as efficient as, the the built in browser caching. Okay. That said, let's, go ahead and move on to PIX.

Christian, do you wanna go first? Sure. Well, since we were talking about, Microsoft SPA Frameworks, I thought I would talk about the previous Microsoft SPA framework. So what was, Daniel, what would you say was what's the predecessor of, Blazor? The biggest inspiration from Blazor, I would say, does come from React.

Like, if you look at Blazor and Sprint, it looks very React like in its methodology. And you're absolutely right about, I was, I was I was I was hinting at some some some Microsoft technologies. So, of course, I'm talking about Silverlight today. Oh. Oh, my We don't talk about I don't know why you're all laughing.

I I mean, it's all embarrassing story, right, that I think I once even even did a book on that. So when we had Richard Campbell on, I was kinda arm wrestled into telling that story. But, last month, there was a new release of, OpenSilver, opensilver.net. So what they're essentially doing, and I thought that's why it's a good pick for today when when Daniel's on the show, is, basically, they're using Blazor WebAssembly to run existing Silverlight and WPF apps in the browser. So they now have f sharp support.

I think they run the Silverlight toolkits with, I think, 0 code changes or very little code changes. So, actually, a a a customer of mine who was was stuck with with the old, slot app, they they have been using that to kinda don't know to say save their project, but, essentially, they they were able to to reuse their their existing, their existing code. And, so I I thought that pretty amazing also that this this project is is still active and, well, again, had the release in, early February. So that's my pick. Christian, I have to I have to tell you the little little background there.

So Yeah. Please do. One one of the funny things like, we we get asked a lot about, like, you know, is Blaze gonna be the next silver light? Like, are you gonna is, like, a silver light, you know, had an unfortunate end of life and then people get nervous because of the the similarities they see there. The say the the dot net web assembly runtime that we build for Blazor is the same dot net web assembly runtime that Open Silver uses to create a Silverlight experience in in the browser.

So in some sense, Blazer is responsible for resurrecting Silverlight again through the Well, you're growing your own competition. Is that We get recurring credit for obviously, the the the maintainer of that project, he does amazing that team does amazing work, and they've done a phenomenal job helping the existing Silverlight customers. But, yeah, under the covers, under the hoods, it's blazer. Okay. I think I'll go next this time.

So my pick this week is called Rachio. It's a smart, sprinkler controller for your your your lawn, and if you got a automated sprinkler system, and the old ones were just set on timers, just on off, on off, whatever days you want. And about 8 to 10 years ago, I bought this ratio or ratio, whatever you wanna call it, smart controller. And just a couple weeks ago, they sent me an email that says, hey. Your controller is really old.

Why don't you take 50% off a new controller? I said, So since my green, grass is starting to grow, and it's springtime and things like that, so I went for that. And I really like it because, you know, you can. It's smart. It knows the weather.

It knows humidity, temperature, wind, all that kind of stuff that takes it into account of when to run your sprinklers and when to not. You tell it the slope for this zone. You tell it the type of soil for this zone, and it just does all the AI generated controlling of your sprinkler heads. And so saved you a lot of water and and some money there. So try it out.

Alright, Mark. You will know what's your pick? There we go. I think I'm unmuted. My pick is, a sweet TV show on Apple TV called Trying.

It's about a sweet couple that do sweet things for each other. They're trying to have a baby. And by the way kids, if you like sobbing like a baby, this is the show for you. If you've got someone like a partner in your family, somebody who likes to sob when people do sweet things, this is the show. I'll often walk in on my wife and she's crying, just crying uncontrollably and I know what she's doing.

She's watching this show. It's actually really really sweet, great, a great vision, from the creator behind it. And, I've I've been really impressed with how it it's able even me, an autistic robot man, still it could get me, and I would be like, oh, man. So, yeah, it's a pretty good show. Alright.

Cool. Alright, Adam. What's your pick? So my pick for this week is software again. So we probably know SSH and PowerShell remoting and other stuff for controlling remote hosts.

There is still this all good old tool called PS exec. If you have never heard about that, this is a nice trickery from Sysinternals that lets you actually execute commands on remote hosts with nothing. The only thing you just need is, like, be able to share files, which Windows has enabled by default, and it does some black magic behind the scenes to install the service that lets you do even interactive shell over there. So we can use it. And when can it be helpful?

Well, sometimes we just forget to install open SSH or PowerShell remoting server. TS exit still does the magic. So go check it out. It can really save you when you are in big troubles. It still works, and I don't know how many decades it has been.

But it looks like it's gonna work with Windows whatever comes after 11. I I'm, proud to say I I shook Mark Russinovich's hand 2 weeks ago. Totally fanboying, because all of those system tunnels tools, they've as as as for you, they have saved me so much so much time on so many instances, and they are still maintained. Right? Okay, Daniel.

Do I have to pick up one? Okay. You know, I'm gonna go some with something old school here. I, my my my wife and my kids had never seen the movie, 2,001, A Space Odyssey. Do you guys know this movie?

It's Arthur c Clark. Old classic. And so I said, oh, we have to we have to sit down and watch this. And, that has been just a super fun experience. Like, there's the whole opening.

If you haven't seen the movie, you should go see it. Think of it as poetry. Science, science, poetry. The apes and the bones. Oh, yes.

The apes were there was lots of commentary during the the whole ape scene and the music and, That that movie I think that movie still holds the record for the furthest distance in a jump cut that's ever been traveled through time. Yes. Yep. Yeah. That makes sense.

We haven't actually finished it yet, so they haven't seen the ending. So don't don't don't spoil it for them, but I'm actually really looking forward for them to seeing the psychedelic, like, ending sequence that comes in 2,001. So, yeah, that's my that's my pick. Then you're gonna watch 2010? I don't know.

Like, it's a very different experience. Right? Like, maybe. But at least they got the they've seen how. Right?

Then, you know, oh, Dave. You know, the whole experience. So, culturally, they've been they've been they've been they've learned now what the what the way computers computers might be. I guess it's kind of, relevant in the the new AI world, you know, like, where where are we headed here? Alright.

Thanks, Daniel, for coming on the on the show. Let's not wait so long next time, you know. Happy to be here. Happy to come back. Thanks for having me.

Yeah. Great to have you. For our listeners who wanna get in touch with the show, if you got feedback or ideas for, topics, they can reach out to me. I am on all the platforms. I am at.netsuperhero.

Thanks, and we'll catch you all in the next episode of adventuresin.net.