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