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