>> [MUSIC] Hello everyone and welcome to the May episode of the asp.net Blazor
community stand up. With us today we have Daniel Roth. >> Hello everyone.
How are you doing? I've got to say that is now the
coolest opening graphic sequence. About that logo, amazing. Fantastic. >> A lot of hype to live onto. >> We have John Galloway. >> Hi, I'm excited to
have a front row seat. I'm quite excited. Dam was like weeping together
demos during the countdown, like throwing it all that easy. >> Myself and I can invoke. Today we're going
to be talking about some Blazor updates for.NET 8. Earlier this year we did a stream
or be shut our plans for.NET 8. This is an opportunity for us
to show what we have so far. But before we jump into that, we will start with
some community links. Let's get started with that. First we have Blazor ApexCharts, which is a wrapper
around a chart library, a jump strip chart library
called ApexCharts, which is a cool way to add interactive charts to webpage and
as a part from our Vanilla JS, angular, react vue, but also Blazor. They have a pretty cool
demo site that shows all the different types of
supported charts as well as code examples for
how to create them. It's really easy to get
started and copy and paste some code into your own project
and mess around with it. The charts are really
cool, very interactive. If you need that
functionality for your app, then give this thing a look. >> Fancy [inaudible]
really those look great. >> Next we have a blog
post by John Hilton. This is about when Blazor
components re-render. There are a lot of different
ways or a lot of reasons a component could be
re-re-rendered in Blazor, maybe it's perimeters
changed or maybe an event got fired and it had a handler
and the component or something, or you call state has
changed but this blog post goes over all the reasons that
a component could be rendered. If that's ever been a topic
that's been convincing to you, like when do I have to call
state is changed then maybe this blog post can help
clarify some things and also goes over some things like how
things work under the hood. Give that a look if that's a
topic you're interested in. Next, we have a set of examples for how to use the MVVM
Toolkit with Blazor. The MVVM Toolkit as part of
the.NET Community Toolkit, which is basically a set of UI platform agnostic
helpers for Don apps, and the MVVM Toolkit
is part of that. MVVM, if you're not familiar, is a UI design pattern
that's familiar in lots of different types
of C-Sharp UI frameworks, but it's less common to
Blazor and there isn't yet a official plays or MVVM sample. If you want to use that
pattern within Blazor, get this example look
and there are also some accompanying blog posts
that come with that as well. Next, we have a podcast or an
episode of the.NET Rocks podcasts. This is actually from late March, but its featuring
Steve Sanderson and Javier Nelson from the Blazor team. >> They run in the big
guns. That's great. >> The topic for that
podcast is, on this page, it's called Blazor United but
it changed that phrasing, so we're not calling it
Blazor United anymore. We're just calling it the
Full-stack Blazor effort. As you're listening to this
podcast just in your mind, replace every occurrence
of Blazor United with Full-stack Blazor
because we're calling it Full-stack Blazor going forward. But anyways, this podcast is really interesting that go in-depth
on someplace united topics. If you're interested in that,
which I'm sure many of you are, please give that a look. >> It's a really good podcasts. I actually was at a conference in
Romania and I got a lot of it. I was teaching a two-day workshop on ASP.Net and I got a ton of
questions on Blazor and said, okay, we'll take all
your Blazor questions on the second day of the workshop. As I was walking to the workshop, it's as a 20-minute walk, I listened to this whole podcast
and just to make sure that I had all my tech details. It was like super helpful. A lot of great
technical detail here. >> Definitely. Cool. That leads us to the last community link,
which is boltonblazor.net. This is a pretty cool
site that just has a giant collection of websites
that have been built with Blazor. There's some really
cool ones on here that I've never seen before like there's this stock scanning app that's
pretty decently complicated. There are a lot of full featured apps basically on this
page as well, some simpler ones. But if you're looking for some inspiration or
just some cool examples of apps that are built with Blazor, get the side of look, has a lot
of really neat stuff in it. >> I think this site
is built with octane. This is shown Walker's
project I believe. This is the a CMS style
system built on Blazor. That is I think then hosting
this built on Blazor website. It's Blazor on a multiple
layers all the way down. >> I think I may say
something in the footer. >> Built with octane. >> This is octane. >> Awesome. >> We had Sean on to talk
about octane a while ago. Might be good to get an
update from him sometimes in. >> Definitely. That wraps it
up for the community links. I think Daniel I'll
hand it back to you. >> Man. Thank you Mackinnon. I was just looking at all the chat. This is a global stream. We have people from all
over the place, Lebanon, South Africa, Italy, Tanzania, I think I saw earlier.
Welcome everyone. I don't know what time
zones it is for you all, but if you're like in the
middle of the night to watch The Community Standup
we appreciate you being here. Thank you for joining. We're going to do an update on all the new stuff that we're
working on in Blazor in.Net 8, we're going to look at some of
the features that have made it into the most recent.Net 8 previews. We'll do some demos. I have a few demos with some stuff that's coming
in the next video. We'll be shipping shortly, any day now within the next week
or so. That'll be fun. Then I'll talk a little bit about the roadmap for some
of the other features like ones that are still coming
down the pipe for later in.Net 8. Let me move this over here so I can see what and I'm talking about. Can you see my screen. Great. In.Net 8 one
of the big themes for Blazor is that we're
working to combine the benefits of the
server and client into a single consistent
programming model based on Blazor. Modern web apps today they use a variety of approaches to
handle their WebUI needs. Like maybe your
homepage or your blog. That's best handled with server-side rendering so that it
loads fast and is easily indexed. In.Net 8 today we have support for server-side rendering
with MBC and Razor pages, but for other parts of your app, maybe you need more
elaborate functionality, needs to be responsive. That part is probably best to run from the client using
client-side rendering. For that in.Net we of
course have Blazor. But in order to use these
two different approaches to WebUI together in.Net App, you currently have to mix
different frameworks. In.Net 8 what we're
working on is we want you to be able to use
these two things together. We're combining the
strengths of the server and the client into a single
consistent programming model based on Blazor, so that you can build full-stack
WebUI using Blazor components. This will all be from within a
single project that you can have. Islands of interactivity placed
on either Blazor server or Blazor WebAssembly alongside
server-side rendered content. You can easily switch
the rendering modes and even mix them on the same page. That's what we're working
on for for.Net 8. Now Mackinnon mentioned earlier, some of you have probably
heard us refer to this effort previously as Blazor United, but that name gave an impression that I think
led to some confusion. This, isn't a new framework. This isn't even a new
hosting model for Blazor. Instead, it's actually
just a collection of new Blazor features and
enhancements in.Net 8 that make Blazor a true
full-stack WebUI framework. To avoid confusing
people into thinking that we're building
something completely new and completely
different,we decided to actually move away
from the Blazor United naming and instead just focus on the actual features that
we're adding to Blazor. It's really just Blazor in.Net 8. What are those features? Well, there's five main
features that we're working on in the.Net 8 timeframe. Server-side rendering
with Blazor components, streaming rendering, which I'll
talk about what that is in a bit, enhanced navigation and
form handling and adding client-side interactivity on a per
component or a per-page level. Then also the ability to choose which components render mode
that you want at runtime. These are features
that we've shown in prototype form with the recipe app. Maybe you've seen Steve Sanderson, Blazor United YouTube video. That's where that name
originally came from. We started using it and then it
started creating some confusion, so we've now decide
to move away from it, but really what Blazor United
was just all these features working together to create that
full stack WebUI experience. Now some of these features
are already available to try out with the
latest.Net 8 previews. Others are still in
the works and will be available in
upcoming.Net 8 previews. We're going to look at what's
implemented so far in.Net 8. If you want to see all of
these features in action, then you probably should
go check out either of the previous Blazor
community standup that we did where we showed
allow these features or you can go watch
Steve's YouTube video. Now most of you are probably already familiar with server-side rendering. We've had it available in.Net
8 and with asp.net for, a long time in one form or another. Server-side rendering
means generating HTML from the server in
response to a request. In the case of Blazor, what this means is
that we will route requests to a Blazor component, which is acting as an endpoint. That component renders
the HTML and it gets sent down in the response. Now in this model
there's no WebAssembly, there's no websocket connections
involved you're just getting plain HTML rendered to the
browser in response to requests. This is different
than Blazor server. In Blazors Server, you actually have a persistent connection and states being managed on the
servers so that you get that full interactive experience. In traditional
server-side rendering, the connection only lives as long as the requests and the app
is typically stateless. That's, what we mean
when we're talking about traditional
server-side rendering. We're not talking about the
Blazor server model and in this case. So what
does this look like? Let's do a quick demo
of how you can do server-side rendering
with Blazor in.Net 8. Let me switch over here to
razor server-side rendering. I'll get to this other
demo in a second. Here's a Blazor application and this app is completely
server-side rendered. It popped up over here
on my other window, there it is. Looks
like a Blazor app. We've, of course, got that
lovely purple gradient that will just live forever, that
timeless aesthetic. At some point we should do our design refresh on
the Blazor components. Not every Blazor app looks
like the purple gradient, but for now it's still got it. Now you know it's a Blazor app. If we look at the page
source for this page, you can see that it is fully
rendered from the server, like we're getting fully
rendered HTML in the response. There's nothing happening
client-side to set up the DOM. If we bring up the
browser dev tools, and let's make clear
out all the caches so that we know there's nothing happening here from a client-side
interactivity perspective. Let's refresh. Then
all we're getting, there's no.Net 8 Al-Azm in here. There is this one WebSocket
connection, it's not Blazor server. That's a piece of tooling that enables the browser to
refresh as you make changes. That's not a Blazor
server WebSocket. There's nothing set up here for
client-side interactivities. Is a stateless server-side
rendered Blazor app. Otherwise it looks the same
like we have the homepage, which is just some static HTML. We have the counter. If we click the counter button
though, nothing happens. There's nothing that's set up here to handle that on-click handler. We don't have interactivity yet. Hence, this little warning that
I added to this page and say, don't expect client-side
interactivity with this. Apparently I'm going
to need to restart. >> Let me start later. There we go. I'm not going to restart now. Then the fetch data page, that works just fine because all of the weather forecast data can be retrieved on the server
rendered right into the page and weeks we see
it in the application. Now how is that setup in code? If we go look in program CS to
set up server-side rendering, we're calling add razor
components so that all the relevant services and
then we add mapping all of our routable Blazor components to actual endpoints that will be in
the endpoint and routing sense. Here we're passing the
main layout component to MapRazor Components so that the API knows where to look
for the routable components. It'll basically in
this case only look in the assembly where that main
layout component lives. Now, otherwise, the
code for this app looks almost entirely the
same as a normal Blazor app. Let's take a look. We
got our index page. This is the normal index page
that you'd see in a Blazor app. I added one thing which was I added this component parameter
so that I could pass in a message and use
that for the heading but otherwise normal
index.razor file, the counter component is exactly the same except for the little
warning that I put on the top. There you can see that on
click handler in this app, it's just doing
server-side rendering. There's nothing set
up to handle that, that on click handler yet
in the future we will allow you to add islands of
interactivity like this. And then the fetch data component is literally character from
them saying there's, there's nothing
changed in fetch data. Now, where's the root of this app? Like normally in a Blazor app
you have like an underscore host.csshtml file that's
like the root page or in a Blazor Web Assembly app
you have like index.html which is as static HTML file that hosts
the rest of the application. Well, in this case, the layout
is the root of the application. Like we have our root HTML tag in the layout component and
then this is setting up the frame content for each of the pages in the app
but there's no script. We're going to haven't
set up any client-side anything yet in this application, we're just rendering the body of each page into the
layout and we're done. Now you may have also
noticed that there is no app.razor file here. There's nothing that's actually
setting up the Blazor router. There's no client-side
routing happening. All the routing is happening
using endpoint routing. We're not using the Blazor
client-side router in this case, that does also mean that there's no concept in this app
yet of a default layout. To apply the layouts,
all the components, I'm just using this imports
that razor file and then using the @layout directive to apply the main layout to
it to all the pages. That is how that's all working. Now this model of having a MapRazor Components call where we just find all your
routable components and set up endpoints for them. We think that's going to be the
most common pattern for people who are using server-side
rendering with Blazor. But there are some other approaches
that are available as well. For example, you can just route to a Blazor component
using endpoint routing and that's what's
happening down here. Here in this call we're
mapping slash route, this route to a Blazor component. We're using this razor component
results, which is a way that you. >> Could bump that font
size up just a bit, Dan? >> That better? >> That's great. Yeah, thank you. >> We have this razor component
result that you can use to render a Blazor component from an endpoint route or in a second we'll see also could
do it from a controller. The component I've picked
here is just the homepage, the index component,
and this is where I'm passing in a
component parameter. That's why I set up that
little message parameter. I'm specifying what message should
appear in the main heading. So if we go back to the app and
if I browse the slash route, then we hit that route and our
parameters being passed in. We see hello from route now
instead of hello world, we're still getting the layout
that's because of that underscore import.razor file that was applying the layout to all of the
components in the application. The homepage has caused
the layout baked into it. That's how you can just route to
any Blazor components you'd like. We can do this from MVC
controllers as well. Up above, I do have
an MVC controller, actually named MVC controller
and it has an index action. It's also returning a razor
component result again, that same index component, the homepage but I'm passing in a different message this
time hello from MVC. Now if we browse to
slash MVC slash index, then we should be able to
hit our MVC controller and that again returned with laser component in this case has
the perimeter hello from MVC. That's the way that
you can now render content from the server
using Blazor components, very similar to what you could do
with Razor Pages or MVC views. But now you can do it with
laser components and have the strengths of the Blazor component model
available to server-side. Now we are also working on enabling support for form
handling so that you can do forum posts to a Blazor
component and then just handle that using our normal
like Blazor edit form, where the logic for handling the form posts lives in
your like on valid submit, event handler and we'll have model binding and
validation there as well. That's coming in stages. They like the first parts
of the Blazor form handling support with server-side rendering
will happen in pre-before. You'll be able to set up
the endpoint for handling the forum posts and some very low-level APIs for
getting at the form data. In Preview 5, will be adding the actual multi-body support so you can bind to strongly typed objects, and how will the validation
systems kick in. That'll becoming in the next
couple of preview releases. Is there questions so far that John and I haven't been
watching the chat very carefully? >> Let me see. There
was one about why do you need to pass the layout to MapRazor Components as well as
using the @layout directive? >> Great question. Let me go
back to the code for that. In the case of the program cs logic, so here by calling
MapRazor Components, the goal of that call is to find all the Blazor components
that you want to set up as endpoints like in the
endpoint routing sense. It's going to go looking
through the types to find components that have
the app page directive. They basically have a route attribute
applied to the generated C#. This API needs to know a lot
assemblies do you want to meet a look in for those
routable components? The pattern that we have right
now as you pass in a type and we'll look in the
assembly for that type. In this case, the main layout. I'm not actually specifying the
layout for the app by doing that, I just picked one of
the components in the main app assembly that I
wanted it to look at for finding the rest of the
routable components to actually apply layout to the pages, that's what that @layout
directive is doing up here. That's basically the razor compiler for each of the page components is getting some code into it to
saying that your layout is the main layout component and
that's how that's working. Now in the future, we are actually
planning to integrate the Blazor router into
endpoint routing so that you can have a notion of just a
default layout like you would in a normal Blazor app today that's
usually set up using the router. The app.razor component with that setting up the Blazor router will most likely come back in a future, don any preview release. But for Preview III, the way you have to
do it is like this. Like you have to manually
apply the layouts and there is no Blazor router being used in
the request flow at all yet. >> Let me see. >> How do you render
component within another component in Razor syntax? >> That's super easy. If I go to the homepage
and if I wanted to add, say a counter right here, you just use the tag syntax. It's the name of the component
looking like an HTML tag. If I run this now. >> What you're showing
there too is the page itself is a component. You're showing a component and
that component right there. >> This index.razor,
that's a component. You define components
in Razor files. Then I'm using the
counter component, which is also happens to be a page, but that doesn't prevent
you from using it as a component if you want to. I'm just adding it to the homepage and that's why now you see a counter showing up on home in addition
to the other home content. It's just tags like this
page title tag up above. That's also a component. That's a component we provided
in the framework for setting the page title metadata
on the small page. It's another example
of a component usage. >> Question from Sean, "For those
of us that have invested in Tag helpers and ViewComponents
where we have to abandon those to adopt server-side
rendering Blazor?" >> MVC, Razor Pages, these are frameworks that
are heavily used and loved by hundreds of
thousands of developers. The code that you're
writing in CSHTML files using ViewComponents and
Tag helpers and partials. None of that is going away, that will continue to exist. What we're doing to Blazor is leveling the app model
so that you can have a full stack pattern for handling both your
server-side concerns and your client-side concerns. It's a component-based
programming model. It's a little different than
what MVC and Razor Pages offer, which is much more requests
reply centric like the request is right there in your
hands and you can mess with headers and all
those that type of stuff. You're really right
there at the HTTP layer, if you want to be there. In Blazor, it's a component framework and we want
the components to be able to, like you have the
option of rendering a component on the
server or the client. There's some more abstraction
insulating you a bit from the HTTP layer so that
you have that flexibility. If you prefer to have a programming model that's
very requests reply centric, right there at the HTTP layer, then MVC is a perfectly valid
choice or a Razor Pages. MVC will continue to be there. Lots of people continue to use it. As you saw with the
controller example, you can start adding
Blazor components to an existing MVC app if
that's what you want to do. We also have the
component Tag helper, where you can take a CSHTML file
like an MVC view or a Razor Page and embed a Blazor component inside of that, that's
also supported. We use that for prerendering
in Blazor server apps. These technologies are
intended to be used together. But we think there's a
big productivity gains to be had by bringing Blazors component model to not
only be used on the client, but also to be available
on the server. Long story short, none of your existing codes going away,
it will continue to be there. You don't have to migrate to
anything. You'll be fine. If you're building an MVC app, you should probably continue
to build an MVC app. There's no need to move
your app to now be completely Blazor if it's
that's not useful to you. Maybe one more. I got a bunch
more stuff I want to show. >> Exactly. >> Or should we just go on actually. >> That's fine. >> Then we come back
to more questions. That's go to the next stage, level 2. Here we go. That was just plain traditional
server-side rendering. Now let's look at
adding and enhancing the server-side rendering experience with some client-side support. The first feature we're going to
look at is streaming rendering. What does streaming rendering do? Well, what streaming rendering
allows you to do is if you have pages that have
long-running async tasks, if you're querying the database
or you're making an API call from the server and you don't want to have to wait
for those tasks to complete, to get pixels down to the client, that's what streaming
rendering enables you to do. You can render the page fully
with some placeholder content. For any of the places
where you're waiting on those long-running async tasks. Then when the task complete the updated content,
we'll go check this out. I'll do you a little animation. You get the original
content for the page while you're doing a long-running
tasks like growing the database. Then when the database
query has completed, the page can render again, it goes down on the
same response stream for the original request, and then client-side logic helpers can then apply the
changes to the live DOM. You'd get pixels on
the screen really fast and your app feels more responsive. Let me
show you what I mean. If I go back to our Blazor
server-side rendered app, we have our FetchData page where we can render
some weather forecast. Let's imagine that getting
the weather forecast data requires making an API call that
takes a little bit of time. The weather forecast data is currently coming from this
weather forecast service. It's just generating a bunch of
random in memory weather forecast. But let's imagine that's actually
coming from a proper service. To simulate that, I'm going to add a little bit of code here to add a task stop delay for a
second as if I'm making an API call to some remote service. Now if we go and rerun this
with just that change, what do we expect to have happened? Well, by default, you need all of the async work to complete on the page in order
for the page to render. If you go to fetch data, let me click away and I click
back to it and click 1, 1,000, boom, then it shows up. It's having to wait
that second while that imaginary API call is being completed before it
can fully rendered the page. We can do better than that
with streaming rendering. To enable streaming
rendering, first of all, we are going to now add the
Blazor script to our layout, got a little bit of
client-side functionality that the framework
will provide for you. I'm going to add
this, blazor.web.js. Then let's turn on streaming rendering on
our fetch database. I'm going to fetch data. Up at the top, I'm just going
to have an attribute to say, I would like this page to have
a streaming rendering support. You don't always want
streaming rendering, it can cause content shift around. It's something you really need to design for in your app
so you opt into it. What I expect to happen now is
that when I go to this page, just you get it immediately. But since I don't have
the weather forecast yet, I should see that
loading dot, dot, dot. Then a second later when
our API call has completed, then there should be an
update that gets sent down to the client and applied with the
actual weather forecast data. Let's rerun this again. Now if I click on "Fetch Data", click, you can see there's
the loading dot, dot, dot. Then a second later the
weather forecast show up. I'll do it again. Click, loading, and then the data, and
that's all in one request. There's no Blazor servers
circuits happening there, there's no WebAssembly involved. This is still fundamentally
stateless application doing server-side rendering. It's just you get that better and
more responsive user experience. That's streaming rendering. That's not available in preview 3. This was using the preview 4 bits which will be available very soon, within roughly the next week or so. Now, that's basically what we've got implemented in
the.NET 8 bits so far. Things that we still plan to
enable in.NET 8 that we've shown in prototype form is enhanced
navigation and form handling. In this mode, what Blazor does
is it will intercept whenever you navigate to a new page or
when you submit a form post. Instead of letting that
reload the whole page, it will do the request
using a fetch request. Let's say you click on something, Blazor will intercept that
navigation to a fetch, and then take the HTML
that comes down in the fetch request response and intelligently patch
that into the live DOM. This means that you don't get like the screen blip when
the whole page reloads, it feels fast and smooth whenever you navigate
or if you do a form post. If you do a form post and
you get the response, you don't lose the scroll position on the page or any of those things. This is not available yet
in.NET 8 preview 3 or in 4. I think the plan is that this
will actually lend a little bit later in the release
around preview 6. Right now we're working on adding the client-side
interactivity pieces, which is what I'm going
to talk about next. In previous demos, we've
shown that you can take a component or
a page and say I'd like this to now use
Blazor or server Blazor WebAssembly so you
get that full interactivity. Imagine that counter
component that we have. We want to actually allow
the onclick handler to be invoked by some piece of.Net code either running
server-side or on the client. That is what we're working
on right now for probably the.NET 8 preview 5
release. Not this month. Most likely next month you'll
be able to sprinkle in a little client-side
interactivity onto a page. This work will also
then eventually include the ability to decide at
runtime whether you want to use the Blazor
WebAssembly model or the Blazor server model
for a given component. Those are things that
are still to come. Those are all the
features that make up the full stack web UI effort
in.NET 8. But there's more. We're not just doing
the full stack web UI. We have a bunch of framework
improvements that we're also doing, which I'll talk about next. Now, before I go onto those,
was there any questions about the enhanced navigation or
streaming rendering, interactivity? >> Yeah, there's a ton of questions, but the important thing
is to sort through which are the ones
asked in this section. I think this one's good here. How does streaming
rendering work on the wire? >> I don't know how well I
can show this. We can try. Let's see. Then let's clear that. That looks right. Browse. If we
look at the waterfall, maybe. It's all a single
request and I don't know how much we can see
and it's a second long. How do I [inaudible] Like that? I don't know how to get the more. Where's my side scroller on the depth browser depth
tools [inaudible] tool. What you should see on the
wire is its one request. The initial request from the browser hits the server and you get a full payload of HTML
with the loading dot, dot, dot in the source. I think we should see that
in the source. Let's see. Then we got the [inaudible]
That's interesting. Why it treats that as the source. I'm not actually sure why
that showed that way. The initial source that you get
has the loading placeholder. Then Blazor basically receives
an additional streamed payload from the server that it then applies to the live DOM with the actual
weather forecast updates. It's like doing clever DOM
manipulation at that point, which was one of the
nice things about basing this programming model on
Blazor is that Blazor knows about how to look at
the DOM and figure out what's changed
and update things. On the wire it looks like a
request response just that there's an additional payload that comes
later after the first response. >> There's more general questions, but that's probably the main thing. >> I will say to just
give me a minute, we will do those things later. Let's talk about static
site generation. One of the nice side
effects of adding server-side rendering
supports to Blazor in.NET 8 is that you can now also render a Blazor component completely
outside the context of ASP.NET Core. You can take a Blazor component
and render it to an HTML string or a stream from a console
app. This is really useful. We know a lot of people
like using Razor as a templating language for things
other than like HP responses, maybe you're generating HTML
fragments for a variety of reasons. One common reason is that
you're trying to auto-generate emails from the server in
response to user interactions. You can now use Blazor components
in.NET 8 in order to do that. It's pretty straightforward
for me, let me show you here. This app is not a web application. This is just the console app. We just have program CS and what
we're doing is first of all, we're just setting up a service
collection container because we're using DI and setting up blogging. Then we're going to use
this HTML renderer API, new API in.NET 8 to render
a Blazor component, I have a very simple Blazor
component right here that's just going to print out the current time. But this component can
be arbitrarily complex. You could use a whole
component hierarchy in here if you wanted to. Then we just call render component async and passing the
component that we want to render, you can pass it in
component parameters. Here I'm just passing in
an empty parameter set. Then you can render
it to an HTML string. You can render it to a text
writer wherever you like. Now, the one little tricky
bit is you do need to render the components in the context of
a Blazor component dispatcher. That's what this dispatcher
property is doing. You call dispatcher.invokeasync, and then in here is where you do
your actual component rendering. But if we run this, we should see that we just
get the rendered HTML from a Blazor component just as a string or as a text file
if you wanted to do that. We hope to use this in the
future as the basis for static content generation support
in Blazor applications as well. That's not plan
for.NET 8 but it's on our longer term roadmap of
what we're planning to do. We hope this will enable a bunch of cool scenarios for
people building tools and templating type of
functionality in libraries, you can now use Blazor components
as a basis for doing that. >> This is so cool. I've followed, there have been a lot
of open source efforts to try and shoe horn this in people reporting email
notifications, all things. Template HTML, it's always been, you know and then T4 templates are all different templating systems so that people are
going to love that. >> Yeah. We've always had this
tension on the ASP.NET team that we built Razor and
Razor was designed from the beginning to be a
general purpose templating engine for not even
necessarily just for HTML, for anything, but we use
it heavily, of course, for generating HTML from the
server in web applications. A bunch of things got tied up in that and it
was always hard to pull resources away to handle non-web scenarios
given that was where our main focus and scope is. We're really excited also that we've been able to light
up the scenario for people that are interested
in using Razor in this way. That's generating static HTML
content using Blazor components. There's a bunch of additional
Blazor enhancements that we've been working on as well. In.NET 8 we are planning to ship
a stable release of QuickGrid. QuickGrid is our fast and functional data grid component for Blazor. It's great for simple scenarios where you want to show a
bunch of data on the page. We have added support for sections. If you're familiar with
NBC and Razor Pages, they've had sections support for
a while where you can create outlets for content that then get filled in by pages
in the application. In Blazor, we're adding
that support as well, but based on components using the new section outlet and
section content component, you can now route to named
elements on a page like using fragments style
routing so that's coming. Then we've also enabled
support for monitoring circuit activities so that
you can detect idle circuits. I'm just going to
show you what all of these things look like in code. First of all, for QuickGrid, it's easy as actually just to
go to the QuickGrid demo site. Aka.msslashblazorslashquickgrid. I think this is all
Blazor WebAssembly. This is a Blazor WebAssembly app, is hosted on GitHub
pages that demonstrates the QuickGrid component
and it supports pagination and it supports sorting. You can put little widgets on
things so that you can filter. If we want to look at the
Olympic performance of Canada, we can do that. We can do virtualization. This is another QuickGrid
that's rendering 22,000 results from health. I think it's like
medications data-set. As you can see as I scroll, the data's getting
filled in as I scroll so that you're not having to load in
all 22,000 results all at once. You can virtualize the dataset. You could do styling on it, it uses normal CSS styling, if you want to have this
wonderful enterprise, grid styling designed
for your grids, you can do that too. Now, QuickGrid doesn't support
every single data grid feature. It's designed to be a
good and simple solution for basic use cases. If you need a fully
featured integrated, we would still encourage
you to go check out the various data grids from the control vendors
that are out there. They have wonderful lasered
data grids that you can use. But for a lot of simple scenarios
within QuickGrid it's useful. We previewed it with dotted
seven, in dotted eight, we've decided to just
go ahead and ship a stable and supported release. That's QuickGrid. >> I've played with it a bit.
There's a lot you can do there, with templating, you'd like
including images there, you're showing a simple flag, but there's a lot that you can actually do with that and the virtualization support
is really awesome. >> Yeah, it's very functional. It's similar in flavor too. If for our old-school web forms, at least we have a data
grid control and web form. It's in that same
spirit and something basic that's just there
that you can use. But there are lots of other great
data grids in the community and also from the control vendors
that are also worth a look.- >> Another question, are there new features being
added to QuickGrid greatness? >> We don't currently planned to expand the functionality
and actually I think we decided to pull column resizing actually
from QuickGrid.NET 8, the doing column
resizing correctly in a very framework general way was proved difficult when we
were doing the API review. That was actually a feature
that got removed from.NET 8. Take a look and see what
the feature set has that demo site pretty
much demonstrates every single feature that
the quicker it has enabled. If you think there's something
that's just super basic, that should be there let us know. But we are trying to
be keep it scopes, we're not trying to be the
Devexpress Infragistics, Telerik, data grid of the world, they know what they're
doing and we want to let them continue to do so. But for basic scenarios, QuickGrid is quite sufficient. >> One other thing there
you mentioned in passing, but that demo site is hosted on a GitHub pages static site, right? >> That's right. Actually, it's using a really cool open
source project, Jay Sakamoto. I forget how pronounces
his first name, but he does a lot of really cool
Blazor open source projects. He has a static site
generator library that he has built for
existing Blazor framework. But even without the work
that we've done in.NET 8 that we use on that site to improve the performance
of the site even better. Thank you, Jay Sakamoto
for your contributions. >> I get a link for that. >> Let's talk about
sections support. Sections super easy feature to use. You can define outlets for content using the section outlet component
and you can give them a name. Here I'm defining this outlet
in the main layout.razorfile, and I'm putting it in the top row, that top bar that's on the
default Blazor template. Then when I want to fill in
this outlet with content, you just use the section
content components. Here's section content
on the homepage, and I'm just putting in
some static content here. Again, you'd be
reference the same name to say where you want this to go. On the counter component, I am defining section contents and I'm putting in another button that has the same increment
count functionality as the main counter button
so an extra button. Then in fetch data, I'm rendering
the weather for tomorrow, like the most recent weather report. If we run this, we'll get
to that one in a second. If we look at the homepage, we got home showing
up in the top row, on the counter page,
we see we've got the counter button that's showing
up here and it works just fine. Then on the fetch data page, we're seeing we're rendering
the weather from tomorrow. That's sections. It's just an easy way to have
pages be able to contribute content most frequently
to your layout. This little link here
is also a new feature. This is the ability to link to named elements on a page.
Let me go back to the code. On the fetch data component, I've defined an H_2 at the bottom
of the table that has an ID. Idea of place. Then on the homepage I've got just a normal anchor
tag that links to fetch data hashtag place so that we can link to a
particular ID on the page. This was something that didn't
work in previous spade by Blazor releases but is
now also fully supported. >> There's a few questions
on section specifically.- >> Yeah, go ahead. >> What is the purpose of section
content versus render fragment? >> Let me get my stream
yard backup over here. Render fragment is like I
want to capture a chunk of rendering logic like Blazor
rendering logic and hand it around. >> If you have child
content on a component that usually gets like like
the inside of the tag, that will get captured
as a render fragment, and then the component itself can it gets that child content
as render fragment, then it can then decide
where to render. You can just say like I want
to render this over over here. Sections are
a little different. Sections are like defining a
place holder that gets filled in later by someone else
contributes to that component. You don't pass like a render
fragment to the layout. In this world, with sections, you just say there's a gap, there's a hole here
that anyone can fill. I don't care who it is, whoever. If someone defines
content for this section, you'll get picked up and put there. It's a general purpose
piece of infrastructure, we used it in.NET7. In.NET7, we added support for
modifying the head on the page. If you want to change
the title or add additional Meta tags to the
head section of your HTML page, there was this head outlet
component that you can put there. Then components could
later say the title is this or add this meta tag here. It was a way to define a hole that couldn't be filled in later when there's not really
a way that you can like say here's a render fragment, please put it in the right spot. >> Got it. This is pretty similar to
Section support like in MVC and Razor pages as well, right? >> It's very similar. Yes.
It's similar in concept, but it's component-based
instead of being based on the CSHTML syntax. >> Okay. There's a question here. Can it be required or optional
the same way that MVC does? >> That's a great question. I
can't remember the semantic. Mackinnon, do you remember our
sections required by default? I'm going to remove one. >> Yes. Section
outlets don't require a section content to
render content to it, so it is optional? Yeah. >> Okay. Let me see. One more question here. How does it work with
Cascading values? >> Yeah, so currently
what will happen is cascading parameters
will be inherited from where the section
outlet is rendered. But that's behavior that we're thinking we want
to change by the end of.NET8 so that it inherits the cascade parameter
into section content, which would make more
intuitive sense. There are some other
things that we're looking into regarding Sections, like how do they interact
with error boundaries and how the orchestrator streaming rendering that will have
to polish up before.NET8. >> Okay. A few questions
wondering about like, whoops here, this one here. Do you end up with
collisions if two are trying to or does it just compile them
together or what happens there? >> I think what happens
is the session content that's rendered last
will take priority. There's like an internal wall. Actually [inaudible]
has told it to you, but I think the second internal
stack to keep track of like the order in which
the contents were rendered and then as they get disposed than
the one that's like that was added latest
always shows up. I'm pretty sure that
it is how it works. >> Okay. >> Dan, get back to it here. >> I'll just try
that out system with the double-talk [inaudible]
experiment with these things. They're meant to be
experimented with. The last one, one in
this particular case. I'm going to try. This is actually what Mackinnon
features with this. This is one that's Mackinnon built. I'm trying to do
adjustment, Mackinnon. We might have to set me straight. The last thing was
going to show here is monitoring circuit activity. It dominate, we've added a new API to the circuit handler
API so that you can get notified of inbound
activity on the circuit. Now if you're not familiar
with circuit handlers, circuit handler is an API that has a bunch of life cycle events
for the life of a circuit. Like when the circuit gets traded
and when it gets torn down. That's this right here. You register them in DI, and there's this new API
now that you can use on circuit handler called crate
inbound activity handler. It's a very funky API. Anyway, no laughs. You say what you do is you
take in it gets handed a next pointer that you get, and then you can choose to call and then you're supposed
to return a funk. That's your actual
handler that will get called as inbound activity occurs. It's very much like the middleware
pipeline if you're familiar with middleware and
a spin on that core, very similar style of setup. What this allows you to
do is because you get notified when an inbound
activity occurs, you can look for idle circuits, like circuits that aren't
being used at all. The idea here is that we're, this is the one of the
first pieces to enable you to manage your circuits. Like if you want to evict
circuits that aren't being used like a users just sitting
there, not using the app. You want to save on
server resources. Circuits are UI server resources,
connections and state. You might decide to evict a circuit that appears to not to be used. We haven't actually added
the eviction APIs yet, but we plan to do that in a
future.NET8 preview release. The way this is implemented in this sample is I
have a timer that we just reset and restart every single time some
inbound activity occurs. If that timer ever elapses, then it's raising an event on
the circuit handler instance, and then this gets registered in DI. I've added the idle
circuit handler, and here, I'm specifying an idle time out of just five seconds for demo purposes. Then on the homepage of this app, I am injecting the
idle circuit handlers so that I can hook into that event, and just so I can
display a little bit of UI whenever this
circuit goes idle little. The page goes to sleep
if you're not using it. Let's go ahead and run
this. Here's the app. If we just let sit, then this five seconds has elapsed. The circuit went to sleep, if I start clicking on things, I'm sending inbound activity and
I stopped, wait five seconds. We get all these. This works with
multiple pages, multiple users. If we have multiple of
these going as I click on things and just
went to sleep by me, see if I can keep them both awake. then if I stopped looking
on the first one, then it should go that matter went to sleep and I stop
clicking on the second one, five seconds, the other one
will go to sleep as well. This is a way you can
detect idle circuits and then in the future will also be able to help you manage
resources on the server. No dark mode sleeping. Sorry. >> You didn't explain it, but
can you go at a basic level, what is a circuit? There are a few people
that would want to know. >> People often use
the word session, but it's an overloaded word. So we made up a new Word when
we built Blazer server to represent the user's
engagement with the app. The user comes to a Blazer
server application that sets up usually a web circuit
connection with the server. Now, there's some state
that's being managed on the server for all
of your components, the components are
running server-side, any of the component
state is being handled server-side as you
use the application. Now, that circuit life can actually
live beyond the connection, if you loose network
connectivity will actually hold on to the circuit state, the server-side state for that
circuit for a little while, so that the user if they
later reconnect they can connect back to that
circuit and keep on going. Like if you went into a
tunnel while you're on the subway or whatever and you lost
network for just a little bit, you can still come back. The circuit is that notion of the single user's
experience with the app, the connection, the
server-side state that's driving their user experience. The circuit handler then is an API that allows you
to look at the circuits that are currently set
up between your app and all the users that are using your application and see
when do they get created, when they're getting
torn down and so forth. Now, you have an API also to tell, are they actually
using that circuit, or they actually sending
any inbound activity. >> Cool. That's the quicker sections routing to name elements
detecting idle circuits. There's a bunch of
WebAssembly investments that are happening in.NET as well. Some of these ships, some of
them are still in the works. We are applying the ship
multi-threading support that is very much in the works
and it's getting near to being previewed in for Blazer applications within
the next month or so. We had multi-threading
support in preview in.NET 7, but it was only available
when you weren't using laser, if you were using the new, was it WebAssembly browser app or WebAssembly console
apps there were these lower level abstractions where you could use.NET
on WebAssembly. In that mode, you could
try out multi-threading, but we've been working very
hard to up level that. It's available in
Blazer applications. That is coming in.NET 8. It's not available in preview app, but it should be available within
the next couple of months. It's a lot of work to harden the runtime to support these
multi-threaded patterns. But we are really, really close now. Hot reload improvements, the hot
reload capabilities of the.NET WebAssembly runtime has lagged
behind what the CoreCLR can do. In.NET 8, we are
pretty much at parody already and we expect to be at
parody in the.NET 8 timeframe. Any type of edit that you could
do with a Blazer server app, you should be able to do with a
Blazer WebAssembly app in.NET 8. Many of those edits
are now available, and we are expanding the set
of available edits as well to additional types of edits that will now be supported
with Hot reload. >> There's a question on Hot reload. For instance,
third-party components, will those updates also be
helping for those as well? >> Like I was saying,
Blazer WebAssembly, particularly in.NET 7, supported a very
limited set of edits, like it could basically do
method body replacement and that was it. In.NET 8, it will have the same
level of support that you get with CoreCLR based applications. Rename parameters and do a
whole bunch more things. I think we are all also
working on expanding the set about it so that more
common scenarios will work, like generics is one that's very
common that we know people hit. If you have a generic type
and you're using Hot reload, that's not something
that's supported.NET 7, that's something that we've
been working on for.NET 8. I think the big one that people
hit a lot though is lambdas that captures enclosing parameters. That's really common when
you have render fragments that are flying around
in Blazer components, that one is still
going to be an issue, I think in.NET 8, I don't think we're going
to get to that one, but it is on our
roadmap to to address. For all those people that send
us the telemetry so that we can look at the product and know what's going on,
thank you for doing that. We look at the most common
hot reloaded changes that couldn't be applied, on something that we
often call those rude edits, which I know is a weird name. But a rude edit is when you get that dialog that
pops up and says, hey, you just made a change
that I can't Hot reload into the apps
you have to restart. We keep track of the signal
of one of the top types of edits that result in that dialogue, and we're just basically
working down the stack. Things will continue to
get better in.NET 8. I think the Lambda one, that's an unfortunate one that
we still need to address, but it is on our roadmap to
address at least in the future. >> Okay. >> Cool. Other things. Jiterpreter is a feature that I'm
super excited about in.NET 8. This is partial Git support on
WebAssembly, which is amazing. I never thought we would
actually get that, and I would always ask about can
we get a Git for WebAssembly? WebAssembly doesn't
really allow for that because loading WebAssembly
modules, what does jiterpreter do? You generate native code on the
fly for the further runtime, and then you load that
instead of having to look at the IL instructions that
are in the.NET assemblies, and that makes things
much, much faster. There was an issue that loading WebAssembly modules required
doing a sync on async load, and that was just at odds with
the way our runtime worked. But there is a facility to do synchronous load if
the chunks are small, and we have now incorporated
that into the.NET WebAssembly runtime
so that you get this a really dramatic performance boost, like for some low-level
operations it's 5X faster JSON parsing
significantly faster. The numbers that I have on the
screen were from when we first shipped the jiterpreter in.NET 8, and these are old, like we has
gotten much faster since then. If you publish your
Blazer WebAssembly app, you're not using IoT, IoT will still be the fastest
because that's basically taking almost everything and turning it into WebAssembly at the expense of a much
larger download size. But a jiterpreter will
be a nice middle ground. It's enabled by default,
you don't have to do anything to turn it on. That will give you much
better runtime performance for Blazer WebAssembly apps. Speaking of better performance, we have turned on SIMD an
exception handling support by default when you're
doing AOT in.NET 8, that should give you a big boost
If you're using WebAssembly AOT. We are working to make Blazer
CSP compatible in.NET 8. That haven't completed yet, but that is in the works. >> I'll admit CSP, I'm forgetting, what is that? >> I'm sorry. Content
Security Policy. >> You want to lock down your app
using Content Security Policy. Blazer currently has
some patterns in its scripts that prevent that. We will enable that in.NET 8. Then we're adding a
new packaging format for Blazer WebAssembly apps, and that makes them
more web friendly. Today we download normal.NET assemblies to the
browser and we run them, which is super cool. But those DLL files are Windows executable files
that they will run within the browser security sandbox. They can't do anything that you
couldn't do with JavaScript like the WebAssembly runtime will run those DLLs within
the browser sandbox. It's basically just a data
format at that point, but we have received reports that some security software takes issue with the download of
DLLs over the web. They are like, what are
you doing? What's that? Windows [inaudible]? No, sorry, you can't download that
in this environment. Restricted environments we
have received some reports that some Blazer WebAssembly
apps are getting blocked. To address that, we're providing a new packaging format for the
DLLs that basically strips off all of the Windows native
NIS parts of.NET assemblies. I mean,.NET Assemblies,
they started on Windows. It's a legacy concept that
they have all these p file headers and things on them
that aren't technically needed to run them in
a browser environment, but they're still there,
will be repackaging them so that hopefully they will
no longer be an issue. We've taught the runtime how to
the also handle that file format. Then lastly we also working on WASI support or
WebAssembly system Interface. This isn't really related
to Blazer directly, like Blazer doesn't use WASI, Blazer runs in a browser. WASI is really actually
about being able to take WebAssembly based code and run it outside a browser like if
you want to run it in a server. In.NET 8 we are working to support the WASI
standards so that you can use.NET to run in WebAssembly based environments that are outside of browser environment, like in a server environment. >> I know it was an experimental, but we had.NET isolator
with something, Dan Roth, excuse me, Steve Sanderson, I'm looking at
your face and said your name. Steve Sanderson was mentioning.NET
isolator and that was using some isolation WASI craziness. Is this related or is at
a totally separate thing? >> It's related. What you will do with WASI is very much
an emerging technology, people are exploring using
it for isolation purposes, exploring using it as
an extensibility model, exploring using it for
like serverless patterns. It's an area that's
ripe for innovation. Steve, of course, being
the innovator that is, has been playing around
with a lot of stuff. He's done a lot of
mind-blowing demos with the WebAssembly toolchains,
I think he has one where, a year ago he took all of
[inaudible] and through WASI got it running in a
browser and a service worker. You could like **** and NBC app
from within the browser itself. >> From the browser tab basically. >> It's not something
you would ever do, but [inaudible] what's possible. The.NET isolator was experimented, he did with using the WebAssembly isolation boundary
as a way to isolate.NET code. A lot of services have models where users can contribute code to the
service and one way or another, I think user-defined
functions in a CDN. Or anything that
allows you to upload some simple logic that the service
is then going to run for you. They typically need a
way to isolate that code safely so that you can't upload
malicious stuff or you can't accidentally harm the service or other people that are
running running code as well. WebAssembly is a
attempting technology to do that because it is based on the off of the
browser security model, so you get some isolation guarantees
by running on WebAssembly. He's been playing around with that. The things that you see Steve do, those are very future-looking, so don't expect.NET Isolator to be shipped in.NET 8 that's
not part of the plan. But we do have the basic core
support for WASI is coming in.NET 8. There is in the next
Preview, Preview 4, there's a very basic template
where you can try running some.NET code on WebAssembly
using the WASI system interface. I can show you that really quick. Let's bring up a terminal. >> To try out the wasi support
and this is, I think you need, you'll need PV4-bits to do
this if you try it with PV3, I think the workload that
thought some of them you need wasn't made available yet. But if you've look the workloads
that I have installed, I have this wasi
experimental workload. By the way, the wasi
support for dominated, the plan is that it will
still be in preview. We don't think it'll be done in.NET, but it's something you can
still play around with. You'll want to install this
wasi experimental workload with dotnet workload install
wasi experimental. That's how you do that. I've already done that, so I don't
need to do that. What I will do is that I will then install dot net new
list our new template, which is this wasi console
app template or wasiconsole. This is just a console app that
will run on WebAssembly runtime. Run your code on a WebAssembly
runtime as a console application. In this case, I think
its using wasi on time. I previously installed wasi time on this machine to
enable that to work. But we can then create one
of these, I thin I have one. Dotnet, new wasiconsole, or wasiApp. Let's look and see
what that's gotten it. Here's our app and it's just,
program.cs, Console.WriteLine. It's got some fancy stuff
in the project file to set up that we want to run in a wasi based environments,
so runtime identifier. By default, this template it
will set up so that it will use basically the dotnet WebAssembly
runtime to then run your app. It's not by default going to create just a single
WebAssembly bundle that is going to be supported as well, but it's not working yet in PV4. I was trying to get it
working before though, this community stand up,
but that is also coming. But for now what we can
do is if I just dotnet run our WebAssembly based
console app based on wasi. What we can see in here is
that it built the app output, and here it's calling into
wasntime and pointing to the dotnet WebAssembly bundle and then running our built application, and then we get Hello wasi console, that's being based off
of the wasi interfaces. Very early initial support for wasi that will becoming available
for you to try out soon. I think that's it. Here's a summary of all the things that we're working
on it all for.NET 8, first column is all of the full
stack web UI efforts with Blazor. Server side rendering,
streaming rendering, enhance navigation
and form handling, islands of clients interactivity
and then being able to decide which render mode
you use at runtime. We have a whole bunch of
framework improvements that are coming as well. The ability to statically generate HTML content
using blazer components, quick read sections, routing to named elements
monitoring circuit activity. One thing we didn't see today is
that we are working to improve the authentication support in
blazer. That's also coming. We should expect to
see that progress on that in upcoming
preview releases. Then on the next slide. >> Sorry, can you talk just a little.we had several
questions about that authentication
support Blazor or can you talk a little bit more about
just generally what that means? >> Yeah. There's a really nice
blog post that Jeremy Likeness put together that talks about what we're doing with all up in indoctrinate. In general, we hear
a lot of feedback about how setting up
auth and dealing with off particularly in like spa style apps if you're
working with Angular, working with React with an ASP.Net Core back end,
that's difficult. Blazor WebAssembly
has similar issues because its also
basically a spot app. The way we set up off for
those products today is we do a full OpenID Connect to dance with. We use a third party component
for the OpenID Connect provider. We use Duende's identity
server component. Duende identity server has since
moved to a commercial license. The fact that we still include
it in the template has been, bit controversial. It does have a free offering if
you're doing it for open source or if your company is below
a certain revenue amount. But it is fundamentally
a commercial license. We are moving away from using Duende identity server
in our templates. Instead, we are for most spa scenarios will actually
move to using samescope. We are providing endpoints
for ASP.Net Core identity that you
can then use to call to get data about
users and even issue tokens if you need to do token-based authentication
from a mobile application. We'll be shifting to more cookie-based model for our default templates
and then also providing endpoints for acquire identity for handling getting user information and also token issuance in debate. For more details, I really
encourage you to go look at the authentication blog post. It lays out all aspects
of this effort. Cool. Then lastly, it was just the
WebAssembly investments. Multithreading interpreter,
Hot Reload improvements, SIMD and exception handling, CSP compatibility, and
the Webcil CIO packaging. Wasi should probably have
a preview thing after it. That's an effort that
we're starting a.NET 8, but we'll probably release in a
stable form, post on it eight. For all of the work that's
happening in ASP.Net Core, you can check out our roadmap
at aka.MS/ASP.Net/roadmap. That is what I had for you today. But also, maybe we're overwhelmed. >> We have a few task and questions. Let me challenge you
through some of them. I'll take some of the easiest
ones first. When do we get it? >> November. Every November there will be a dominant release
for now until forever. Until.NET 2763, November
release of.NET. >> You covered it at the beginning, but there's still
some questions here like what happened to Blazor United? Where did Blazor United
go whatever, etc. Blazor United didn't go anywhere, we just decided not to
use that name anymore. The problem with Blazor United as
a name people were saying like, do I have to port my app from
Blazor to something else? Is this a new hosting model? People thought this meant that something new
framework or a new thing. Blazor United really is just a
bunch of new features in Blazor. Blazor United is just Blazor
in.NET 8 to a large extent. It's a theme like a bunch
of features that are around enabling full-stack web UI support. But it's not a new frameworks, it's not a new hosting model, so we decided to
stop using that name to avoid people thinking that
this is something completely new. It's just Blazor in.NET
8, a Blazor web app. >> Let me see question. You
showed some wasi stuff too. Is there like an overlap
with Docker Wasi? >> Docker has been doing
a bunch of cool work too provide depth tooling to make it easy to manage
WebAssembly-based nodes. If you're using the Docker
tooling and you are spinning up some WebAssembly code and you
wanted that code to be.NET code. You could use the.NET wasi
sdk in order to do that. >> Ripping through these. Jiterpreter, AOT, and webcil address file
size and loading speeds. >> Jiterpreter addresses specifically runtime
execution performance. Up till now, the.NET WebAssembly runtime has been
a.NET IL interpreter. It's very functional. It's small
as far as.NET runtimes go. But it wasn't particularly fast at executing CPU-intensive workloads, and that's because there's no JIT. With jiterpreter,
there's now a JIT tier to the.NET IO interpreter
that will take chunks of your.NET IO and turn them into WebAssembly code blobs and then load them asynchronously so that
they execute much faster. That's runtime performance. AOT is also about runtime performance and it
will go up even faster than jiterpreter-based performance
because it's taking basically all of your code and
turning it into WebAssembly, but at the expense of a
much larger download size. When you take.NET IO and
turn it into WebAssembly, you end up with a lot
more instructions than the original.NET IO had, and so the size of the
code base gets larger. No size of proven there. Webcil is about making Blazor WebAssembly apps more friendly to
restricted environments that don't like the transfer
of the DLL files on their network or like an
antivirus software that thinks that anything that looks
like a DLL must be suspicious. It's a more web-friendly
packaging format that we're introducing for.NET 8. It may slightly decrease the download size because we're stripping off
some PE file headers. We're basically taking
the.NET DLLs and removing stuff that is
associated with Windows native executables while
we're talking probably very negligible size
improvements there. In.NET 8, in terms of decreasing the download size of Blazor
WebAssembly apps per se, it's pretty much the same
story as what we had before. We have the IO trimming, we have the WebAssembly
linker capability to re-link the runtime to shrink it. We do compression. We tried to make the
app as small as we can, and the smallest Blazor
WebAssembly app is still about a megabyte in.NET 8. Where things I think are
game-changing is the idea of leveraging server-side rendering
in your Blazor applications. There is zero JavaScript bundle size or WebAssembly download size for
a server-side render application. All the hard work got
done by the server. The page loads like that. It's instantaneous, the best possible load
experience you can imagine. Way better than doing something
with React, or Angular, or Vue, or whatever because you don't
have to download a bunch of client-side code to render the page. You can take content in your
app and just server-side render it to make it load very quickly. You only need the client-side pieces when you're doing rich
client-side interactivity, the parts of your UI
that need drag and drop, or things like that. >> I am forcing my brain
not to say United, but the improvements in
the hosting model and component model that you
showed at the beginning, you could use those together, you can use server-side rendering
and then the interaction is just as you need it or
streamed or that stuff. >> My goal today was mostly just to show what is currently
been implemented in.NET 8, but we've shown in
previous demos that when you add it like an
island of interactivity, like you have a page
that you wanted to have a place or server circuit
associated with it, the circuit only gets
created when you browse to that page and
then when you browse away, that circuit goes away. Your resource allocation is just limited to people on that
page when it's needed, as opposed to being the whole app. Same thing with WebAssembly. If you decide to have a component that's going to use
Blazor WebAssembly, we download the
runtime only when you go to the part of the app
that actually requires it, and then once it's
cached, of course, any future use can be reused. We are also planning to
support the auto mode, where you could start out
a user with Blazor server, which has a very small download size in order to just set up
the WebSocket connection. All the works really happen on
server side with Blazor server, but then we sneak down the WebAssembly
runtime in the background. Then once it is cached, the next
time the user comes to that page, they can use WebAssembly
and you can offload, instead of doing all the
work from the server, you can now handle it from the
client and the user never saw the load time hit for
having to pull down the WebAssembly runtime
because it was done in the background in a clever
way. So that's coming too. >> Let me see. The questions are coming in faster than we
can answer them. Let me see. Here's one I guess. Do all
the client-side components end up in the same wasm
binary or can they be partitioned out in large apps? >> They can be partitioned
into multiple binaries. We often call them
Razor Class libraries. These are just libraries
of components, they're DLLs,.NET assemblies that happen to contain Blazor components. That's why we have
this cool ecosystem of components that you can
just grab off of the NuGet. QuikGrid is just a NuGet package that has a library in it
with the QuikGrid component. You can have multiple assemblies. The question really becomes, when do those assemblies get
downloaded if you're dealing with particularly the
WebAssembly-based model where you're going to move
stuff over to the browser? By default, everything just
gets downloaded at once. We download the entire app and its dependency graphs so
then you just have it all. In general, with most
Blazor WebAssembly apps, the main bulk of the
size is the runtime. The DLLs are typically fairly small, so they're not as much of an issue. Now that's not always the case. There are.NET assemblies
that are large, like Newtonsoft JSON
is a common offender. If you just randomly pull in a dependency into your
Blazor WebAssembly app, that dependency is,
no, three megabyte. Well, you're going to be downloading a three-megabyte DLL to
load your application. There's a couple of ways
you can mitigate this. You can use lazy loading, which is a way in Blazor
WebAssembly to say don't load this assembly until I tell
you. You can do that. I only needed Newtonsoft.JSON
on this page. I'm only going to load
on that one page. You don't need it by the way. You should just use
System Text JSON. It's faster and it's built for
linking and all these nice things. That would be your
JSON stack of choice. Maybe you have some
other large dependency. You can limit it to only be loaded on a particular
page with lazy loading. If you have a large dependency
that you have some influence over, you can make sure that that
dependency supports trimming. So.NET and Blazor, we have the ability to go looking at the code and statically analyze what code is actually
being used in the app and trim out all the code
that's not being used. It's very similar to tree
shaking in the JavaScript world. But by default, we only do it if the assembly
says that it supports it. Assembly has to have an
annotation on it that says, I have done the needful work to make sure that I work
correctly with trimming. Because if you're just
going to randomly remove code from an assembly, it might be doing weird
reflection or who knows what code-gen pattern that
might need that code still and the trimmer doesn't know unless the library has been
appropriately annotated. We've done all that
annotation work for our framework like placement core, the core framework libraries, those are all set up for trimming. If you have a dependency
that you want to use, check to see if it's got
trimming enabled on it. If the library author
has done that work. If they haven't, ask them, if they'd be willing
to do that work or maybe it's a library you
own, you could do that work. There's wonderful docs on how to author a library that
supports trimming. If it doesn't support trimming and you can't get it
to support trimming, then you might want to consider
a different dependency. You do have to be mindful
in Blazor WebAssembly apps, what dependencies you're
pulling into the application. Don't just pull in
stuff willy-nilly, because then you'll end
up with a 20-megabyte size app and that's no good. You want to be intelligent about what your WebAssembly
dependency graph looks like. >> Then maybe move some of those to a server-side API that you call
second layer. All that stuff >> Any dependencies
that are big that you still need, just leave
them on the server. You could use a Blazor server
model as one way to handle that or put it behind an API that you call from your Blazor
WebAssembly app. All those things are possible. >> I narrowed it down
from 20 questions, I've got four left for you. >> Going back to the things you
showed way back at the beginning, could some of those be used
in a Maui application? >> Maui apps are Blazor Hybrid apps, that one is a different
hosting model. In the Maui application, we're hosting the Blazor components directly in the Maui application. They're running on the same.NET
runtime that the rest of the Maui application is
using for its logic. Then they render to the web view through a local interrupt channel. They're not actually running
in the web view itself, there's no web assembly being used, there's no web socket being
handed over the Internet. It's like Blazor server, but instead of a big
long web socket, you just have a little tiny
local interrupt channel with the web view. That's the way you
should think about it. Everything that you've seen with
the full-stack web UI features, these are all features
really for web applications. They don't really apply to
the Blazor Hybrid scenario. I'm trying to think
if there's anything here that would be relevant. There is some interesting ideas
that we have been thinking about, it's a variant on the
hybrid model where, but in.NET 8, the plan
is that you can have a Blazor app that's
largely server based, it's doing server-side rendering. Then it extends itself to the client and just to
places where it's needed. Maybe it does some Blazor
web assembly stuff in just this one part and that happens
client-side in the browser. It's interesting to
think about, well, what if we had a Blazor
app that's very similar. Its server centric, but it has the ability
to extend itself into a native client application
as opposed to the browser as almost like a custom
web browser built for it where the app happens
to already have been packaged there and it
knows how to run.NET code. That's an idea that we've been
chatting a little bit about. Nothing planned for.NET 8, totally future looking, but if anyone wants to try and
experiment with those concepts, it might be a cool open-source
project to look out. >> You showed the HTML renderer, can we use CSS isolation with that? >> That's a great
question. CSS isolation is largely a build time feature. If you have components that
have.Razor,.CSS files, you're using the Razor SDK in
order to build those components. Well, so the HTML render is all about taking a component
and rendering its HTML. The whole CSS layer usually gets
applied by the browser later. You then take that HTML, you stick it in a browser and you download the CSS that you want
to apply to that HTML. You can build the
CSS bundles and then deploy if you're hosting this as a web app or as a static site
and then use them that way. So in that sense, yes, but HTML rendering itself, no. It's not render it's just
about taking the component and rendering its content, which usually doesn't include
any of the CSS stuff, your markup and your styling are separate [inaudible] I think I
got that one right [inaudible] >> That sounds right to me. >> There are a lot of
questions on circuits. There's one in here about
detecting an idle circuit saving state to local storage
serializing somehow. >> Yes. This gets into the whole
pause and resume feature set. We know that people
really want a way to better handle scale out with
Blazor server apps where you can take the state of
a circuit and drain it and then save it
and then be able to rehydrate it elsewhere
or rehydrate it later. These are all things that we
are working towards and some of the ability to monitor activity on the circuit
is in that direction. The pause and resume
feature to allow you to do all this state management for Blazor circuits has been
something on our roadmap, I think for two or three releases. We've had to keep pushing it
out because of other things. In.NET 7, we had to
push it out because of the Maui effort took longer than we expected and we had really
wanted to do it in.NET 8, but all the work that we're doing to enable server-side patterns with Blazor ended up taking
taking priority. We still have that on our roadmap to enable at the framework level. The pieces that we're
delivering right now are not everything that you
would need to do that, there's probably more
APIs that we need to add to make the experience good, but if anyone finds an
innovative way to handle some of those problems with
what we currently have that would be great to
share with the community. >> Cool. Hopefully an easy
last question for you here. Is Juterpreter automatic or do you have to do something to
take advantage of it? >> It is built to be automatic. One constraint is that it won't execute if the app is
built in debug mode. It only will be used if you're
doing a non debug based build. I think in Preview 3, there's an issue where for
Blazor web assembly apps, we always run the runtime in debug
mode so the Juterpreter during development always starts
itself off, which was sad, but that's just during development, when you then publish the application
and you do a release build, then Juterpreter should always kick in and it's just on by default, you don't have to do
anything to enable it. The intent is that you also
can see the benefits of the Juterpreter during
development as well when you're not running in debug mode and we're doing work
in Blazor web assembly to make it so that if you're not
using the debugger then you can still see the
Juterpreter benefits. >> That was incredible. I will cut off the questions
there, they keep coming in. One was asking about
what happened to the Blazor drawings on your wall? >> I actually still have them. They're sitting on
the floor next to me. I was doing some prerecord stuff and I was worried
those pictures were going to be distracting
for the prerecord [inaudible] so I took
them down for that. They will go back up. It was a much to my wife
and children's chagrin [inaudible] dad do you really
need to put those backup, we drew those years ago and
you don't need them anymore, and I'm like, no, I love
them, they're going back up. >> Awesome. My last question, for people wanting to keep up with and go deeper on any
of the stuff you showed, is best reference the.NET blog? >> Yes. >> Okay. > Check out the.NET blog. You can download.NET 8 by
going to get.dotnet/8 to get the latest bits and we will
be publishing details about the upcoming preview
releases on the.NET blog pretty much every month. Look for new bits every month. >> Very cool. Well, this was super long and we've got more and more people joining in
the longer we go, which is crazy. I think we should just turn
it into an all day event. >> Well, it usually
goes the other way. >> Awesome. Well, thanks. This was amazing. Last
question here coming in, are there recordings of
the community stand-ups? Yes, there's hundreds of them
going back seven or eight years, so yes, they're all up
on our.NET YouTube. So I guess with that we
should play the outro music and then you can install
your Windows update. I've been choosing the best gift to play here and I think
this is probably the best. >> If we didn't get to you question, you can ping me on Twitter or you can ask questions
on GitHub as well. Feel free to reach out and
we're happy to chat with you. >> Awesome. Well, I'll play the outro
music. Thanks everybody. >> Bye everyone. >> Bye. [MUSIC]
