How'd you like to listen to dot NetRocks 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, we'll get you that and a special dot net Rocks patron mug. Sign up now at Patreon dot dot NetRocks dot com. Hey, welcome back to dot NetRocks. This is Carl Franklin and this Ridrid Gammon. This is going to be a great show, Richard.
I'm expecting nothing less.
Yeah, Dan Roth is here and it's also show nineteen hundred and twenty two, and I'm summarizing what happened that year from the peoplehistory dot com.
Okay.
In nineteen twenty two, significant global events shape the world. The Union of the Soviet Socialist republics USSR was formed, solidifying the rise of communism in the UK. The British Broadcasting Company or the BBC was founded, making the start of public radio broadcasting. In science, the first successful insulin treatment for diabetes took place in Canada. Of course, Canada,
of course, it was meanwhile and refused to patent. It actually published the specification so that anybody could make it.
Because you guys are polite, well and you know you do the right thing. And we don't want to we don't want to make people alive. Cost a lot of money.
Who would do that?
Now? I don't know. I don't know.
I just make it mad by saying things like that. Meanwhile, the discovery of King Tut's tomb tooked uncommon, captivated the world and in Italy Benito Mussolini ros to power. The Lincoln Memorial was also dedicated in Washington, d C. Commencing President Abraham's Lincoln legacy. Yeah, and that's only something that you probably have things to add.
Oh.
No, my favorites of that year would be toot In Commons tomb and the insulin. What else? What can I think of?
Uh?
Egypt becomes independent from Britain.
Yeah, okay, just was that before or after King Tut's tomb was well, it was discovered, because wasn't it an Englishman that discovered? Yeah?
Howard was an Englishman, no question, do you remember it was? It was a pleasant handover. It was a civilized han, right and it's not like the British army actually pulled out they you know, it's more of the like can It was sort of like they filled in the form and made the deal. Wasn't a big revolution or anything.
Yeah, have a have some champagne. Okay, it's all yours now.
See well, I mean it still turn into bigger issues thirty years from now with the Suez Canal crisis. But you know we'll figure it out that. You know, you've got a year and a half before we have or a half a year before I have to talk about that part thirty episodes from now.
Yeah, I like this. I like this trajectory we're on here. Okay, it's very informative. Okay, let's roll the crazy music for better no a framework?
All right, man? What do you got?
Well? I know that you know, Microsoft is all ai ish these days. It's word definitely ai ish. So I saw this and I don't know really anything about it. But this was posted on dev Express's blog on September eighteenth. New dev Express AI powered blazer Chat component Early access preview. So it's a new UI library design to incorporate AI driven interactions into your next great app and deliver responsive, copilot inspired interfaces with absolute ease. Again, have it checked
it out? I just saw that. It came across my desk and I was like, you know what, that might be a good jumping off point for today.
I also think it's the way we're going to see a lot of these large language model technologies applied is as a ux extension to an application.
Mm hmm. Absolutely.
And it's not not really a product, it's a feature to a product. Yeah.
And and it also makes you rethink your whole UI in general. If you can do a lot of stuff with a textbox, why do we need all these other controls. I'm sure Dan's got ideas about that too.
So all the smart components coming coming to the ecosystem, it's it's pretty pretty fun. We've done some of our own experiments around that in the in Dwton.
I know it does imply that all everything we've done up till now was dumb components.
No, nope, more more intelligent components, don't.
There you go?
Yeah, smarter components. I like that.
Smarter, smarter components.
There you going. And when we get to smartest components and then we're done, we can't go any smarter, more resource intensive components. How about that? Okayeah, that's good. So that's what I got today. Richard, who's talking.
To us, grabbed a comment off the show eighteen thirty eight, the one done by Javier Nelson and Steve Sanderson talking about Blazer United. One of the few Blazer shows you've ever done without mister Roth involved directly. Yeah, though I'm sure he was pretty by the way. This is from March of twenty twenty three, and lots of good comments on this show from from our friends, including Richard Ruhima, who although otherwise known as codeputer yep. On there he says,
this is going to get really interesting. I find this to be a paradigm shift, not in terms of the web, but in terms of building an application for the web. Talking about Blazer United right in this context, not AI Blazer United, where server and client could be intermixed very easily. This unity of Blazer styles, I think, simply relates to where the code resides, which updates the DOM Blazer server. The DOM is updated on the server and the resulting
dip gram of the UX assent to the browser. Web assembly is the traditional approach for server pouring the entire application of the browser just to use client side reasers to update the DOM to unify and the various design thoughts expressed here, I thought I could simplify to say what updates the dom? For example, if I'm using a click event, why can't I attribute that code as server and not attribute the code and have it execute on the client. This is the most granular, but you could
also do it as a component level as well. All data, however, should be streamed in my opinion, but as that data becomes available and is simply defined by where it was requested, I suggested the podcast, I'm going to head over to GitHub and start planning to participate in what I think is a very important development in the concept of web application development.
Richard is a very thoughtful guy. He was one of the guys last year at Codena Castle event and just loved it, and I really enjoyed talking to him well.
And I don't disagree with this core sentiment here that we're getting into this idea of units of compute in the web that could run in multiple places. As a certainly a conversation we've had mister Standerson before. We're not just the client or the browser, but some interim location close to the client but not actually on their machine. Right,
think about us smarter distributed network. Here your local caches that could actually run compute units for you, so that they have nice fast interaction with the browser, but the sensitive data never actually enters a browser unless necessary, and then trips back to the server asynchronously.
The the problem I see with that, and basically we're talking about, is having some button click events that work on the server and some that work on the client. And the problem is that if if you're doing server side Blazer, let's say, uh, it has to keep track of everything in all the time. Yeah.
Yeah, Well but imagine you know you want you want that security of the server side, but you can't handle the round trip. It takes too long. So you have you're able to deploy chunks of code to a CDN close to that browser and have that code execute there and very low latency.
Right, But if it changes the dumb and you're still using a service side dom graph model, that service side dumb graph model has to stay informed and updated.
Yeah, so it's got to work both directions. But I dig it, I think it just gives us options, more options on where to run our compute. Because you know, there's a weird way to think about this, which is a web assembly is almost another kind of container. Oh definitely right that it's a smaller unit of code that can be shipped around and executed on demand where you need it. Richard, thank you so much for your comment. You always bring up some great ideas, make us think
a little bit. I'd send you a copy of music Cobey, but I'm pretty sure you got one already. But if you don't, you know my number, give me a go I'll look you up.
Or does anything else? You want a mug or whatever, just let us know.
Yeah, whatever you want, brother, you know you're welcome. And if you'd like copy of music code By, write a comment on the website of donn at Rocks dot com or on the facebooks we publish every show there. If you comment there and ever ready in the show, we'll send you a copy of music go by.
And you can always follow Richard Campbell and myself on ex Twitter. That's we've been there for a long time. But all the cool kids nowadays are hanging out at Macedon at least I think so. I'm at Carl Franklin at tech Hub dot social.
And I'm rich Campbell at Macedon dot social.
Send us a toot. It's another way you can get a free copy of music to code by if we read your toot. Are they called toots?
I think they're toots.
Yeah, I think they are.
I've been doing a lot of stuff on louse Ky lately too, and if there's anything that Elon's done, he's definitely fragmented this market. Yeah.
I've got a lot more followers on Macedon than I do on Blue Sky. Blue Sky didn't seem to get anywhere with me, but I'm still there. Yeah, all right, so let's bring back mister Daniel Roth. He is a principal program manager on the aspnet team at Microsoft, specifically working on dot net web development with Blazer. What's up, Dan, Hi, Carl, Hi, Richard.
It's great to be here.
Great to have you, Good to have you back. Friend.
I guess there's a new dot net in town coming in November, dot net nine imminently.
Yeah, just around the corner. Every November release, whether you want it or not, here comes. Oh you'll want it, You'll want it nine.
Yeah. Yeah.
So I've been reading the blog posts and I saw the blog post about what's new and asp neet core for dot net nine, and that included a thing on Blazer and I'm very lighted to see that in Blazer Server. I'm calling it the semi opaque veil of death that happens when you need to reload and you know, the connection gets broken and stuff, and that is you're really addressing that with this with this release.
Release, we're helping. We're helped. I think there's still probably some more things that we can do to improve that experience, but yeah, we're making some improvements to the reconnection experience for apps that use the Blazer server model, or as we would call it now, the interactive server rendering render mode.
With Blazer server apps, it's a stateful model, right like you have a live connection with the browser or with the app to function, and you have server state, and if the connection gets lost, then the app has this sort of white overlay that that happens to let the user know like, hey, I'm the app is not going to be able to function right now because it doesn't have that connection. All the uy gets driven from the server in this in this paradigm, and.
I find that users just aren't smart enough to configure that reconnection stuff. They just don't they don't really don't.
Know on the developer side, yeah, that there are things you can do, but it it is a bit manual. In dot AT eight and dot and nine, the goals to try and make the default set up a little bit more end user friendly for the people that are using that that WebApp from that developer.
Yeah, that's great news.
Well, well, things that we'll do now will automatically refresh the browser for the user with when the connection gets re established and if the app detects like oh, the user's circuit like their service side state has gone away
for whatever reason like that. That can happen for a number of different cases, like maybe there was a server deployment that happened because the servers or restart and whatever state was held in memory got lost, or maybe the connection was lost for too long and the server timed out the circuit and so it just freed up that those those resources forever. Reason, if the user state got lost, they kind of need to start again, and before we
would and help them help them with that. And now in DOTTA nine we will automatically refreshed the browser, the UI, the UX that you see that the user sees when that connection gets lost as a little friendlier it's not that white overlay anymore. It's a little like sort of mold dialogue style UI. You can you can customize it,
of course, however you'd like. But the fault experience is a little a little cleaner, and it's a little bit more responsive, like when the server comes back up, the user has to wait less time, Like the polling intervals are a little bit more intelligent in dotted nine, so they get the app working working faster. So that's that's all goodness. To be clear, though, the state on the server is still the responsibility of the app developer. Like
it by the fault is just held in memory. If you want to that state to survive, you know, sing things like a server restart or the cirt of going away and coming back, you do need to still write code in your application to persist state and rehydrated again when a user comes back and wants to resume whatever it was that they were doing. So that that problem is still very much an application developer problem. In ten or some future Donnet, we still hope to create patterns
in the framework that make that a little easier. That's something we in and I hopefully we'll get in the future I.
Have a pattern for that actually, and I'll post a link to it. It's on a GitHub repo. And what it does is it you create an interface off of your app state, cascading parameter or cascading value that you want to persist, and then every time that gets anytime any of those variables get touched or changed, it persists those And so you can take that whole idea of using protected browser storage, or you could save in SQL
server whatever you know, but you save it. You can even save the page that you were on right, the form you were filling out, and the fields that you've entered in the fields that you haven't entered, Like, you can get down to that kind of level.
Yeah, which, by the way, delights people. Right, Is there not better than going back to a page you didn't finish and the work you've already done is still there.
Oh yeah, it's terrible if that doesn't happen.
Well, I think it's expected if it doesn't happen, which is why it delights when it does. Like, there's not the tremendously difficult things we have to do, they're not make people's lives a little bit better and to have them smile at our software instead of frown.
I had it. I remember this experience and you guys probably have two. When I was I was applying for a loan online and I got you know, there was like nine pages that I had to fill out, and I got to page seven and it said, oh, by the way, which one of these dollar values was the payment of your mortgage, you know, two years ago or whatever? And I'm like, what now I have to go. I have to walk away from the computer, go to the file camp. By the time I came back, it said
to your sessions timed out. You got to start all over again. I'm going to someone else now.
Yeah, yeah, yeah, yeah, this stuff doesn't have to suck. And I appreciate you built app server thinking in terms of this is just a component you could add in and have that behavior happen. Yeah, that's a good idea.
So what else you got, Dan so well?
Dotted eight obviously was the big move for Blazer to become a full stack web framework, like you guys were mentioning earlier, the Blazer United effort. That was the early code name that we used for a name name of that technology of uniting all the Blazers into one thing. Where you now it's just.
Called Blazer, the Blazer web app as well the way, but you can have different render modes that you turn on or off inside your Blazer web app to light up different functionality in different places.
And so that model really unified the web development experience for for dot Net, like whether you're doing server or doing client, you can do it with just one component model using Blazer components, and it really positioned Blazers our you know, our our primary our rec commended solution for building web UI starting with with dot neet eight. But it was new, like there's certainly user experience gaps in that in that in that model that we're still ironing
out and filling in. The reconnection experience was was one thing we did. Another is giving you more run time visibility into which render mode is currently active. Like just as a to walk you through a very common Blazer flow. You might make the initial request to a Blazer web app and it will render HTML from the server statically, like just give you some HTMIL immediately. We often call
that pre rendering. That's a form of just static server side rendering where you get HTMIL down to the browser as fast as you can so you get pixels on the user's screen as quickly as you.
Get stuff floating look at.
Then you might have interactive features though on that page that you want to enable, like you want to handle those button clicks or drag and drop or whatever, and you have a choice on whether you do that from the server using interactive server rendering or from the client
using web assembly based rendering. Now, while you're waiting for that interactivity to light up, there might be interactive features on the page that aren't quite functional yet, like the counter button if you try to click on it in that split second before interactivity has been enabled. There's nothing yet set up for to handle those UI events or due to do dynamic UI updates. So what you can do now in Dota nine, we give you a runtime
API for detecting the render mode. So when you do that first static service side render, you might maybe disable the interactive features or don't render them yet, like wait until interactivity is now live, right, and then when the component renders interactively, like through from the over the web socket connection or on web assembly, you then light up those interactive features so they're now available for the user to use.
So you have this.
Capability now of structuring the dom, adjusting the component rendering based on how that component is currently being rendered, which render mode is currently act.
Nice and saving and low state is kind of important, right, because if you go from an interactive thing where you've got some state to a non interactive thing where you don't, and then back to an interactive thing, what happens to your state? Right?
You might you know, yeah, you need some some way of flowing that around, and that can be that can be tricky, you know, you mentioned earlier options like I think I think this is sort of one of the the industry trends right now in front in web development that the frameworks are getting are getting very powerful in terms of the the flexibility and how you render your components, Like you can render your components from the server, you can render them from the from the client, and various
mixed cases as well, like enhanced uh static, enhanced navigation and forum handling, streaming rendering. These these new patterns that enable you to make your app more feel, more responsive, load faster, have a better user experience, but it does also result in complexity, like and it can result in like these types of architectural questions that you're asking about like, well, how I now flow state from each of these different types of rendering within my application.
Yeah.
I think that's something that you know in general, not just in Blazer, but like whether you're doing React or Angular, you know, React server components, our thing right next JS has similar patterns or newer frameworks like Astro and solid like figuring out ways to help users navigate the complexity of these different ways of rendering. Web UI is I think an ongoing, an ongoing, challenging problem.
Yeah.
Yeah, just to be clear, you can use some props. So when dot Net eight came out, Rocky Laca and I noticed that there was some problems with scope services just sort of dying and going null on you when you switched modes. And that seems to have been fixed. I didn't see a lot of fanfare about it, but I tried it recently for a talk I was giving and lo and behold those scope services are now surviving the in it. Yeah, which is great, which is great.
So I mean working is expected, there was Yeah, working is expected, but you know, there's like he said, there were some glitches with dot and it eate when it came out, and some of those things are being correct and hats off man. Good stuff. Laser goes on.
Laser continues to do to improve we do. We do try to listen to to user feedback. I think they're still like with state and persistence, like we were talking about you know, your own libraries to helping with service
side persistence. I still think there's more to be to be done, Like we've wanted for a while to have like a more declarative model for persistence in Blazer where you can sort of declare on your component, like here's stuff that I'd like to be that's awesome persisted or survive the pre render to the interactive rendering flow and all these places where you want to flow state around helping with framework patterns UH to deal with those types of types of issues, and those are things I think
we'll look at in a future version.
It's cool, very cool. The relationship with MAUI. I mean they'd come up later than you know, Blazer's been around longer and there's sort of this energy around this is your you know, all purpose client environment. What are you guys doing.
We have a great partnership and integration with with MAUI. I mean MAUI is all about cross platform native client apps like you want to use, and Mali really specializes in enabling you to use the native view y controls and elements from the underlying platform. You when you render a button, yeah, and you're gonna get the iOS button. When you are on an Android, you get the Android button, or when y you get the winduw I button. That's
their their bread and butter. Where we plug into Mali with Blazer is well, you can render a WebView control within a Maui app on regardless of the platform you're on, and from that WebView control, you can then render Blazer components from from the device. So this is what we
call the Blazer hybrid pattern. And actually, Donta nine we have a new solution template I guess we could call it for doing both a dott Maui Blazer hybrid app in conjunction with a Blazer web app where you want to target not only the native client platforms with your Blazer components, but also the webs web, mobile and desktop with one template setup. That's something you could do in Donna Dight, but you had to kind of set it
up manually. It was a bit bit tedious and Dota nine we give you a pre kit.
It is a bit inception, ye, right, that you have an UX inside of a framework inside of a UX A little bit, yeah.
But it's very common. Like we use these style of apps all the time. If anyone's using Visual Studio code have a native shell with a you know, chromium based web view sitting inside of it. Your editor Microsoft teams is built with a similar technology stack of similar similar architecture or hybrid style architecture. Sure, the Blazer hybrid pattern just lets you do it with Blazer components as opposed to having to do it with JavaScript, right.
I also like the fact that you can mix a match, Like you can build a WPF app that has a Blazer view for your main content and then hey, if you can't find a good Blazer calendar control, you can use a WPF calendar control and pop that up right, and you know what I mean, it's just wind forms or vice versa. Yeah, So you can truly use the platforms inside the different platforms inside of an app for what you know, the best of breed technology is whatever.
I was talking with some of the Maui folks, and I think in some cases they like if if there's a control that's not quite available or not quite working the way people want. At the native layer. People often will go the Blazer hybrid rout to go grab a control from you know, popular web frameworks or Blazer that use that inside their mauway up and that that works very quite quite quite well for them.
Yeah, I just wonder about performance behavior, Like there's all the subtleties that work when you're pulling in components through these different layers like that, like does this UX hold together? Does it look like this is a different component stat that came from a different Blazer. Does it look like it's all unified?
Yeah? That that's so. The thing you lose out with the Blazer hybrid pattern is you are now rendering web UI within the native shell. If you've stuck with just native native controls like the MAUI abstractions. For those native controls, you get the look and feel consistency of that platform, Like it'll look like an iOS app when it's running on iOS, it will look like an Android app when it's on Android. Once you go into the hybrid world you're now in that.
It looks like a web app.
Yeah, well, however you style that that web app you want it to look IOSC. Then you're gonna have to use some CSS styles that make it follow the iOS design patterns.
Or if you want all your textbox to be in flames, yes, CSS will do that for you.
Yes, you can do it.
All your text box are belonging to S.
Yes. No applying for taste here, that's not it.
I want you want to mention like for performance. I actually think that the Blazer hybrid pattern is is a really good story for a performance because the rendering of the Blazer components is happening natively on the device. Like there's no web assembly involved. No, there's no website get involved. You're running your dot net Blazer components on a normal dot net run time with JIT and normal garbage collector
and all that stuff running on the device. It's then just talking to the WebView control over like a local interrupt channel. So the component rendering is quick. That's very performant. You do have a little extra weight because you are bringing the web platform with.
You as soon as the web control comes into play. That's a spicy meatball, right, yeah, and spicy meat.
And you can look, you know, you can look at the task manager and see the difference right. The native Maui stuff is smaller, right, and then you have the in the in the process for the for the Blazer Hybrid, you've got you know, edge webe chromium, the WebView and all of the stuff that comes with it. Right. So yeah, yeah, you aren't going to use more memory.
You're going to feel it now that last time I look, most of these machines have way too much memory anyway.
So I totally agree Richard. Never run out of memory on my iPhone to take back.
The memory so they don't have so much to waste.
I had. I had a group in here in the studio the other night when we're recording something, and he says, you know, he's trying to punch in and and I said, dude, I'm not going to run out of tape.
It's gonna be okay.
You know, you can go as many times as long as you want. You can just keep recording. He's like, oh, stop, go back, you know. No, no, not gonna run out of tape, not going to run out of memory.
I'm not going to stop. It's not going to just have one continuous stream, keep going. It's like my phone's not running out of film. It's going to be take another picture.
It's okay, right, Yeah, yeah, this is just leftover behaviors from old technologies.
Yeah, I mean there is a phones have some constraints they but mostly bandwidth related ones and storage related ones depending on what phone you're getting. But yeah, definitely we have you know, maintainability is more important these days and optimizing the bites.
Still, when my phone starts running low on battery, the first thing I do is close all the apps that are running there.
You go, well, I just swapped up my phone because the last one started to grow in the way that says this will catch fire soon.
So you mean like capacitors.
No, the battery started to expand popular expanding Yeah, yike. Not a good sign. No, not at all. So I moved on. Hey, we should take a little break, and then I.
Get some questions. All right, we'll be right back after these messages. Did you know you can lift and shift your dot net framework apps to virtual machines in the cloud. Use the elastic beanstalk service to easily migrate to Amazon EC two with little or no changes. Find out more at aws dot Amazon dot com slash elastic beanstalk. And
we're back. It's dot in a Rocks and Carl Franklin, my friend Richard Campbell, Heye, and our friend Daniel Roth from Microsoft in just as a reminder, if you don't want to hear these ads, because let's face it, some of them you really don't want to hear, you can for five dollars a month go to Patreon dot dot nerocks dot com and become a patron and you'll get a feed that's ad free.
Nice.
All right, where were we dan? What's on your list next?
What have we covered? So?
I think it's important to stress that for DOTT nine, a lot of what we're doing in this release is about quality and fundamentals, like the features always get the headlines right, new new capabilities, new functionality. But a pretty significant investment was made in DOTTA nine just to focus on things like performance, security, accessibility, just making sure that the fundamentals of what we're shipping our top top quality. I'm sure many people listening have heard of the Secure
Future initiative from microclock. The whole dot net team has been participating in that effort as well, making sure that every feature we ship is secure by default, has secure characteristics for our users, and that's all.
Work, expects to expects to managed identity, like those kinds of things, right, really doing the zero testing.
Making sure our samples show you best practices for the latest threats and how you mitigate them, and just making sure that our own infrastructure, of course is is as tight and as secure as it possibly can be, a lot of works gone to security performance, though it is always a big area of investment.
There is Steven tow isn't there.
Has published his tomb Yes, the tome.
Taking I know what I'm doing this weekend.
I gotta say, like these these perform I know he does a lot of like micro benchmarking part of showing those benefits, but these benefits are real. Like we Donnet is used heavily internally at Microsoft by our largest products, you know Microsoft teams being in Tune, Xbox, like these huge properties are using don net to power their back ends and they just love that. Every donnet version comes out, they install that on to.
Change nothing and things are faster. Actually, some of my favorite blog posts have been like the team's team saying, here's our benchmarks. When we were on seven, and then we switch to eight, here's the things we needed to fix, and then we ran the same benchmarks again and here's our performance on eight. Like those, I think are very compelling for folks to see Microsoft consumes its own dog food, like this is a product they use and they are
getting these benefits too, and they care about them. Absolutely, Yeah, absolutely. I would tie that back to the Secure Future initiative in the sense that it is still too hard to write really secure code, but I'm glad you guys are doing it because it will then get easier because you need You've got deadlines too, right, and as soon as security gets in the way enough that you're serious and considering circumventing it, like you know where those guys work, go get them and make it better.
Fix it.
Well, I remember what happened to WPF when the studio team started implementing it back for the twenty ten edition. WPF took this massive leap in improvement because those guys rang it out and found its weaknesses and then hunted down the folks who built it and made it better.
And the dot Net Framework the same thing happened when it was embedded in SQL service. Yeah, shook it out, They beat the snot out of it.
Things get used, they get refined in the the world.
Yeah, but it's also there's there's a little insider angle there where one Microsoft team's being impeded by another Microsoft team. Like that gets energy right that you can actually make step better. That will all bet of fit from. Like I expect our process of making secure dot net applications to get dramatically better the next year.
It is a goal that as we improve our own security, that that spreads to the rest of the eCos rolls out to everybody. One example I can think of is like one technique we're using internally on our code basis is you know, static code analysis scanning, scanning our codebases looking for problems in an automated fashion. One of the tools we use for that is code ql, which is a publicly available suite that's used as part of our
get up Advanced Security offering for scanning codebases. And so as we you know, tweak and refine the rules that we use for scanning our code bases, then those can become available to external users and that that whole story just gets better and stronger, so you can find issues faster in an automated way. So security top top priority.
You know, huge amount of resources being spent on making sure that our uh that that that our users can trust the products that we ship from Microsoft because everything else rides on top of.
That getting back performance from it, and just this will give you a good segway for you. Uh. I recall several years ago. I don't remember what which version of dot net it was, but it was like, for the first time dot Net was outperforming. It's uh, you know, not its rivals or its adversaries, but it's competitors. It's competitive stacks in terms of you know, speed and performance. And you know, at that point I was like, ah, okay, dot Net is the most performance. I don't have to
worry about that now. But then you know, of course every year those competitors' platforms also increase their performance. And you've got this cat and mouse team, So what is it in terms of performance? Do you know what the rank is in terms of compared to everything else.
The benchmark that we use for that and that we target and Donnett is the Tech and Power Benchmarks, which are a public set of benchmarks that look at all the developer ecosystems that are on the planet. They implement the same suite of benchmark tests and then they run them and you can go and look and compare how
different implementations of different stacks look against each other. And I don't have the numbers off the top of my head, but you can, of course just go and check the tech power benchmarks yourself.
And we were Richard's doing that area.
Well, yep, very very well on those benchmarks.
You guys are always in the top few, right, I mean the the.
And usually it's the top few where we're like often the one that is like the thing you would actually consider using, like some of the other there are some.
Right, yeah, some of these stacks are pretty weird.
Academic I would say there are some other good stacks out there. I don't want to say there are.
Sure, yeah, there's plenty. There's plenty of good stacks. But there dot net Core sitting at twenty three out of what two hundred, three hundred, five hundred.
Say pretty confidently that if you choose dot net for your service stack, you will be very happy with its performance.
Character performance will not be an issue. That's it's not going to be an issue.
And that's proven out in the real world by like we were talking earlier about us running down it in our own data centers, for our own cloud, for our.
Own product offering.
Okay, so Dan, I hate to put you on the spot, but if I ask you this every time I interview you, back when dot net was just coming out, dot net server, you showed at dot ne kof a slide where you did a headless test of the skew that Blazer server
was running on. How much RAM and how many CPUs versus how many consecutive users you could have, not consecutive concurrent, how many concurrent users you can have before a click result doesn't return in two hundred milliseconds, which is kind of the brain benchmark by which people think it's slow. And you said that I think it was five thousand for like, don't know, four gigs of RAM, and if you increase that to something in for CPUs, it got more.
And the other thing that you said was how much overhead blazer server used for each user to keep the state, to keep the dom and back then I think it was eighty five k. Do you have any idea, I mean, you probably don't have a number, but would you expect that number to go up or to go down?
With the number to go down, give them amount of performance tuning we've had, but I don't think we've run that test again since we did. It Initially was done as sort of a just a proof point to show that Laser Server wasn't going to be the bottleneck for a good chunk of apps.
I think it was.
It was act like it was a fairly small VM that you could run five thousand concurrent users and.
A more yeah, like a gig of RAM or something.
Yeah, and a more reasonable size VM you could easily handle twenty thousand concurrent using Blazer Server. Of course, that changes as you add your own app logic, like if you start allocating a bunch of memory for each circuit for each user, then that will yeah, that's baseline change the dynamics. But as a baseline, Blaser Server can certainly handle quite easily with fairly reasonable hardware tens of thousands of current users without sweating. And Microsoft do that all the.
Time on one server, And this question I get asked all the time, and just to so that everybody can not make sure that I didn't lie to them, I'll ask you. So, if you want to scale out Blazer Server, you use the signal our service from Azure, and so then you can scale out add more servers, right, so if you're twenty thousand concurrent user servers and enough, you add another one. But by default affinity is on, so
connections are sticky. So when somebody comes in and they log in and they register, they're always using that server, so you don't have to worry about, oh, this time when they press this button, it went to this particular server which doesn't have my state. So is that that is true?
Right?
That is still the pattern You need to have session affinity in order to run Blazer server apps because it is a statefold.
It's on by default in an app service, I think yes.
And the signal Our service, what purpose that serves is helping you with the connections scaled out, Like if you have a server environment, we're flooding it with you know, tens of thousands of concurrent web socket connections might be an issue. They signal ADUs signilar service can help multiplex those connections so that your server infrastructure is less loaded on the at the connection part of the application in
many Azure services. Actually, we recently updated our guidance around the Azure signal Our service, so it's worth noting if you're using it today. In Azure app service, having lots and lots of website and connections used to be more of a concern than it is now, and so for most of our Azure based hosts, we no longer say that you need to use the adres signal our service in companionship with it, because those services can already handle the number of web socket connections by themselves, so it's
not a normally a problem. But if you have another environment where that might be an issue, then the address Signal our service is a great option.
That's really good news.
And yeah, you added a bunch of signal R features for nine right.
Yeah, yeah. Signal are now has sports polymorphic types, so if you want to like pass an instance of a derived type to to your hub methods, you can do that. There was some work done around its tracing model, like
how how signal handles UH distributed tracing. It used to be that all the hub invocations would kind of appear under one big, giant long request, right, because these are usually long running web socket connections, and so it looks kind of weird when you're trying to analyze the distributed traces.
They now kind of appear more more like you would imagine a request reply style trace, uh looking in the in the traces, which is much It's much nicer when you're like looking at your signal r hubs in like the Aspire dashboard, you get a much easier view to parts to see the what's what's happening with your your hubs. So those are both new on the there's a couple of performance improvements. I also wanted to mention on Blazer side, the for Blazer server or interactive server rendering, we now
do compression at the web socket layer. So the traffic that gets sent to your Blazer server hub, which itself is a signaler hub underneath the cover, so it also benefits from all those signal features too, but that traffic is smaller and therefore has a lower latency and is faster. On the web assembly side, we did a bunch of work on the startup performance of the web assembly runtime.
In the past, we've we've focused a lot on shrinking the download size so that you can get the bits for the dotted web assembly runtime onto the device as quickly as possible, and that is still important, and we we've shrunk that thing of as far down as as we can, and we look for ways to improve that, but there is also still some latency that can occur when you then boot it up, like you say, okay,
now run the runtime. That can take a you know, some some number of milliseconds to actually get the runtime started, which also delays the the interactive state of your app. So we focused on that and dot at nine and sped that up by good like I don't remember the exact number, but something like twenty thirty percent faster runtime
startup performance. And then broadly for asp dot Core, we did a bunch of work around static web assets, like the static files that make up your your web applications, whether this is a Blaser app or an NBC app or a Razor Pages app, anything that lives in your dubdub root folder. We now will build and publish time identify those static web assets and do a bunch of
optimizations on them. We will free the print their filenames so they have unique caches in the filenames that enables us to then aggressively cash them when they're being served, Like we can basically KnowI browsers that cash us forever, because if there's a new version of it, I'm just going to change the file name, so you don't need to worry about that.
Wow.
We also pre compress them at build and published time using Broadley compression. It's very similar to what we've had in Blazer web assembly for a while, but now it's done for any static web asset that you have that isn't already in a compressed format. So thinks CSS files,
jobscript files. The acement core tooling will now do a precompression on those those those files as well, so your static web assets load faster and they're better cased, and that helps Blazer apps as well as any dot Net web front.
And lazy loading comes to mind when you said that, and are you doing any lazy loading automatically in the background of your own assets in the dot Net framework or is do we still can we still benefit from doing that ourselves.
So there's lazyloading and Blazer where you can like sort of take a chunk of your app that gets downloaded to the client and say, you know what, I don't need this yet. I will tell you when I'm going to load this, and then they can be lazyloaded in later that that feature still exists for static web assets. There are I don't think we've we got to this point dot at nine, but on our roadmap we also
would like to do like preloading. It's not not really lazy looad, but like saying like sure, hey, I'm about to go to this asset and i can see that it needs these other files too, so go ahead and preload those into the browser because I'm probably going to request them them soon. Like having links in your Yeah, that's that's smart HDMIL. That's signal of that's that will be the case. That can avoid waterfall style loading of
assets in your webpages that can slow things down. If you can avoid that waterfall, then things will load faster as well.
Very cool.
That's a future optimization that we hope to get to.
Nice hate really great. I'm I'm going to go a little off the beaten path here because I was just going through some of the notes and it ran across this mention of multiple Blazer web apps per server project, which I totally get. I've dug into the issue and so forth, where it's like, okay, you know you've got to comment back end several different clients that they want
to manage in one project. What what I smiled at was when I saw this is tagged for dot net ten November twenty twenty five, and it's just like, man, that's organized, Like we know definitely when this is going to make it for another version, but it just speaks to the whole conversation about this was a user submitting the issue? I think just looking at the GitHub reposts like November of twenty three, so it was it was right after dot net eight had shipped, is when they
sort of post this issue. I'm sure folks were talking about it before then, but I'm just looking at this particular issue, like can you talk a bit about this flow. I don't imagine this is your problem or not, Dan, but it's just interesting to me, like.
How we manage the user feedback and that.
Yeah, and that's whole triage, Like the fact that it's all in gidhub now where people can just write an issue and I see guys like Havia interacting with this issue and you know, taking it seriously and queuing it up.
Yeah, yeah, this is this is good to know because this is how you can understand if you have a feature that's important to you, how you can engage with us on the Blazer team to make sure your your your feedback and your perspectives on these issues is being heard. So all the feedback everything that we do is publicly tracked on GitHub. We are a fully public open source project and that's where we operate. That's where our devs do their day to day work, and it's part of
every release. And we're about to go into the ten planning cycle to think through what are we going.
To do with You're you're in our see now. So there's clearly stuff that's been triaged out to next and it's time and this is probably one of them. And yet now you're starting to sort out like what lives in next?
Yeah, so we we we have a number of different signals that we use to figure out, okay, what what do we want to push up the stack on our on our backlog. The one that's most user facing is if you just go to a GitHub issue and use the thumbs up reactions right to say like this is important to me, and do it on the original post, do it at the top.
Now I see fourteen fourteen thumbs up on that one.
Please don't get this, like, please don't look your friends from a bot network to click thumbs up on these things, because we do use it as a signal, and we know it's a rough signal. Yeah, at least lets us know, like, yeah, I care about this too, so please please consider this. The next, like level two of helping us out is if you could post a comment on the GitHub issue explaining the why, explaining the scenario that you care about and why this is really important.
Well, and you have a nice template here the is there an existing issue? Is it really or fature requests related to a problem? Can you tell us about the problem, describe the solution you'd like, you know, some additional context, Like you've given us some structure to sort of describe the issue to you.
So if you're the one that's posting the original issue, like you're actually the one making the request, then you follow the template, fill out that information, give us, give us as much data as you can on your scenario, your requirements, and why it's important, because that's all stuff
that we read through and factor into our prioritization. Even if it's an issue that you find is already filed, it's still helpful for you to post another comment saying also this is important to me because of X, Y and Z, So give us more perspective.
Right, I mean this emphasis on search first, because if there's an existing issue that you can contribute to, you increase the likelihood of this happening a weight, right, the weight gets bigger where multiple separate requests are less powerful than one big one that everybody's contributing.
It seems to me that before GitHub, you know, if you were to, if anyone were to approach a team member and say, hey, I have this, why don't you implement this feature? Blah blah blah blah blah, that Microsoft team members were programmed to say, why would you ever want to do that? Right? I mean I've gotten that answer, and I've seen them give that answer to in person, because that it's not necessarily a combative question, but it really makes you think I want less compa that I think, no, no,
But I mean it's a great question. But I think that that's kind of what you're doing with GitHub. You know, what is the real issue that you're having. Perhaps you've already gone several abstractions higher than you need to go, and maybe let's get to the core of the problem.
And sometimes that's about us. We want to understand the core of the problem because maybe you're requesting a particular solution, but if you take the more context on what the problem actually is, like what you're trying to solve, that might lead us to a different solution that would work better from a framework authoring perspective, like maybe we can broaden the solution that would help not only your scenario but also these other scenarios and you know, line things better.
So though, the why behind your request is really really helpful.
And the search thing that Richard was talking about is important too, because like in my world, I get probably ten people coming to me a year with ideas for apps. I have the idea, you build it and will split it fifty to fifty. I think it's all the time right, And I always say, all right, before you come back to me again, I want you to do a thorough search to see if that app already exists, and I knit they never come back.
There's a lot of people with the ideas out there. It's hard to prome with something truly unique. A couple of other things though, that are worth noting, So we will. We have our backlog milestone that's where we put everything that's like, you know, something we may consider to do at some point. We often will have a you mentioned a ten milestone, Richard, and usually that's a doit ten planning milestone.
Yeah, and I see it here now as I read deeper into this thing, it's like you can see you the point where when okay, this is going to be in ten like it was initially in nine, and then it would know it's going to make it to ten.
So Donna ten planning is the stuff that we're like, it's kind of like a level above the the just being on the backlog. It's stuff that we have already thought about that we do think is important, right, and we'd like to consider as part of what we're going to do in intent. It almost always has more stuff in that milestone than we could ever possibly sure.
Sure it is like the next it's where you put all the next it might split across more so, it's not.
A commitment yet, it's a it's a planning tool that we used to say, you know, this is probably the first batch of stuff that we'll look at for the dot tent planning. And then we take all the user data that the reactions, we take our our own understanding about where's the industry going, Like we go do you know, analysis on what other frameworks are doing, what's what's happening
on the web platform. We look from that direction, and then we of course look from our own business priorities and from Microsoft pays the bills.
Yep, there's things they need. You're going to have to do those things.
The roadmap, the committed roadmap, and even this commitment is is it's it's our our best understanding at the moment. Roadmap then usually gets published early, like first quarter of the year saying this is what we think we're doing an ACEMT Core and Blazer for say dot ten, and that should published on GitHub. That is still of course subject to change. You know, software development is hard. We we often sometimes we misjudge how much things are going
to cost. Sometimes initiatives come in that change plans, like the secure initiative was certainly something.
That definitely drew resources off change.
Things for dot net nine. So the roadmap I wouldn't view even that as like a guaranteed to happen for the release. It's one of those things actually that I've been we've been trying to improve on. It's like, have that roadmap be more more trustworthy that yes, these things will actually get done, but it is at least our best understanding at that moment about what we think we're going to bite off for.
The I can also imagine that if you implement a feature too soon that it can it can be more of a problem later, So deferring a feature for the next version the next version after that can often come on the heels of an analysis that says, ah, before we solve that problem. We have to solve these problems because that will make this one a lot more intelligent or whatever that we won't have to backfill.
It's for people that maybe get frustrated by that, because it can be frustrating right where you have like a feature that's important that gets delayed from release to release. Might I think the one that's maybe close to people's minds at this point for web assembly is our multi threading support. We've we've had multi threading on our i think on our roadmap now for like two or three releases, wanting to get it done, and then for various reasons
it having to be to be pushed out. Things that the community can do to help out with some of those is that if we are open source project, you can contribute. That includes contributing design thoughts, contributing approaches, helping us work through like how would we actually do this, and even potentially contributing code.
Yeah, I think someone who's frustrated because you haven't got it yet writing up this is what I would use it for, so that you have better case analysis of like this is how this customer will implement this? Are we headed in that path?
Why would you ever want to do that?
Yeah? With with multi threading, so that's the like the why, and like like what problems should solve? You can also help us with contributing and this is how I think would be a good way to solve it, even if it's a straw man proposal that that is a food for a thought. We just went through through this with web assembly, multi threading and DOTTA nine, where you know, we went through design and you know, get up docs,
got written and start implementing that design. And for Blazer, the design we landed on and look like it's gonna be good. This looks So we weren't able to get the Blazer part of the work done and DOT and nine,
so we're still waiting a little bit on that. We pretend, but then we got feedback from other UI stacks in the ecosystem that use our web assembly support like UNO and Avolonia look at look at our looking at our multi threading capabilities, and they have valid feedback about whoa hold on, like this constraint might be problematic for the way we use this feature. And both types of design discussions also super valuable, like please look at what we're doing.
Share you're not every part of the product.
Well you yeah, you're living. You provide a framework in an ecosystem, don't break the ecosystem, like that's we.
Try not to try to make the world a better place for the ecosystem.
Yeah.
Yeah. To imagine a group like you know it's done all kinds of great work where they say, hey, we're not going to be able to use a new version of Blazer based on what you're doing here. Yeah, exactly, Well that would be bad. That's bad for everybody.
This won't meet our needs, that might make Microsoft's needs. And we we want to develop deliver features for the entire ecosystem.
Not But I think it's just you stepping into introduced breaking changes knowing what you're breaking. I'm not saying you wouldn't do it, but you want to have those considerations, like, here's how big the impact actually is. You don't want to ship it and then find out about the impact.
Yeah, I mean, breaking changes are one thing, and in other cases it's just like having a design that's overly constrained or thought about certain scenarios in certain ways, you know, adjusting the requirements based on as broad and inclusive an audience as we can, we can.
Get sure and I could see it'd be worth just pushing back and working a little longer and then maybe a pass the thresholder it's like, it's not going to make this version. Yeah, I mean you're shipping every year, which I think has got to be hard. I know it's hard receiving new versions every year. So I gotta think it's hard on you guys too, pushing these out every year, knowing your ship date the second week of November every.
Time, got a ship one way or another.
Yeah, And certainly other teams you talk to where it's like, oh, this feature has been worked on, spanning multiple versions before we could finally actually turn it on. Like absolutely, that's just that's just the reality. Not everything fits into a year long development, much less how the target moves like you think you know, think about the the FSI. It's how many of the features you're currently planning breach FSI
and need to be reworked to include new security requirements. Yeah, all these things are hard, and it's reality tends to smack you around, right, And I, for one, having been on the side of you ship something that created a bunch of problems for folks, I'd rather you wait.
It, particularly when it comes to frameworks, because when things go into a framework, it's it's hard.
You can't ever take them out. Really, Yeah, taking them out is way way more arduous.
Or convince people not to use that anymore, use this instead.
Yeah, that's that's a tough one, because they got working code on the old way. It's something to see Steve Sanderson's show up in some of these threads and just make a couple of notes or something like that. It's like, it's like this is as demigod, I blessed this, Like dang, you got blessed.
All right, Dan, I want to know who plays the cello in your family.
I play a little bit of the cello. I don't play very much anymore. I did do a little like talent show concert like a couple months ago. So I had it out and was playing it. And I don't know if you ever play a string instrument.
I tried for a year.
Oh yeah, your fingers get raw if you haven't played in a while. So I was getting all the red fingertips. I played through like high school, a little bit in college, and definitely petered off after that. But I still have my cello, still occasionally break it out.
And yeah, I noticed the case. That's why everybody can't see this because it's the radio show. But but there's a case in the corner. Yeah. I tried it for about a year. I was already playing guitar, so I didn't have the fingertip problem, but the stretch, Like you know, my hands are relatively small, and the figure your hands sorry for a cello or bass player. The smaller your fingers are for violin, the better. But anyway, I think it was.
A joke by Frank Carlwoods told me, says, you know what the difference between a violin and a viola is the viola burns longer. This is very How did you know this? We should test it, all right, Dan? Anything else before we jump off?
I get get market calendar for fort comp November. That's when we'll be having a big the big ship party. So we look forward.
You got early bits available now you can early what sorry, early bits are early bits available now?
Oh yeah, the release candidate is already the first release Candidate's already shipped and here in just a few days. Maybe by the time this this episode air, by.
The time this is this publishes end of October, there'll be they'll be you'll be second release candiate too, which really means your interest away. Then it will be a couple of weeks before dot dot com at that point, so it'll be final.
So awesome. Our timing works. Thank you, Dan, always a pleasure.
Good to see you, frank for having me talking with you guys. You bet all right.
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 E t R O c k S dot com for RSS feeds, downloads, mobile apps, comments, and access to the full archive 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. You got JAD middle vans, the
Taxes,