Hey everyone, welcome to the Unhandled Exception podcast. I'm Dan Clark and this is episode
number 37. Now I'm sure most of you are aware that Microsoft will have just had their build
conference, which is an annual developer conference, which normally comes with a whole host of exciting
announcements. Now with me being an avid podcast listener, each year I long for a podcast episode
to come out straight after build, overviewing all of the main announcements. Hopefully this year,
this podcast episode can do just that. But one problem is that I don't know what the announcements
are going to be, because at the time of recording, build hasn't yet happened, but to help me out
on that front, I am very excited to be joined by both Scott Hunter and Gareth Sate, who do know
what the announcements are going to be. So welcome Scott and Gareth, thank you for joining me to the show.
Hey, thank you Dan for having us over.
Yeah, thanks so much. I'm always excited to do these podcasts right around build, always so many fun
announcements and cool stuff that's going to come out.
Yeah, definitely. And you both must be so busy in the lead up to build. So I am so grateful that you
spare the time to come on the show. So could you both introduce yourselves to the listeners and tell us
what you do for both Microsoft, but also for the build conference?
Yeah, so I'm Scott Hunter, and I am the VP Director of Azure Developer Experience. And so I work on a
team that builds a lot of our Azure PAS services. Our team also builds a lot of the developer tools
for Azure across Visual Studio, Visual Studio Code and the CLI. And we build a variety of services
as well outside of PAS. PAS is Azure App Service, Azure Functions, Azure Container Apps, Logic Apps.
But we have lots of other services like Redis Cache and Config Service and a bunch of stuff like that.
And so our job is to make it so any developer can use Azure in any language. And I've also spent a
ton of my career at Microsoft working on .NET, first in the ASP.NET team, and then later back in
Dev Dev working on .NET Core 1 all the way through .NET 6.
Yeah, and my name is Gaurav Sade. I'm the Director of Product on the Developer Platform and
Languages team here at Microsoft. You know, there are three big things that the team is responsible
for. You know, first and foremost, it's the .NET platform and the framework. You know, it comes along
with its set of languages, you know, be it C-sharp, F-sharp or VB. The next piece is C++ and the third
one being Java. So, you know, that's the place where I work in or the technology set that I work with.
And, you know, I end up working across multiple teams across Microsoft, whether it is about, you
know, building support that we offer for, you know, these developer framework and languages,
or whether it's about, you know, building those cohesive end-to-end experience that are cloud first,
you know, cloud native first. So, I work very closely with Scott's team across that as well.
Yeah, I'm a big fan of both, as the listeners will know, both .NET and Azure. So, yeah, all of this
stuff is amazing. So, I'm really looking forward to digging in. So, before we dig in to build, I'm just
going to quickly do this episode's listener mention. And this one goes to Steve Collins,
who tweeted, great last talk of the day at NDC London from Nick Chapsas, about minimal API.
If you get the chance, also listen to him talk to Dan on the Unhandled Exception podcast.
So, thank you for the mention, Steve. I really enjoyed recording that one. It was such a fun
conversation. And if anyone wants to get mentioned on the show, just send a tweet using hashtag
UnhandledException. All feedback is greatly appreciated. And I'm jacking on Twitter,
which is D-R-A-C-A-N. So, in the intro, I very briefly mentioned what build was.
But before we dig into maybe some of the announcements, could we talk a little bit
more about what build is on the aims and goals of the build conference?
You know, build traditionally has been a conference for developers. So, you know,
we have, Microsoft has a couple of conferences during the year. I think of the build conference
being the developer conference. There's the ignite conference in the fall, or in the October
November timeframe. And that's typically for, you know, IT professionals and more than developers.
And so, for us, you know, for Garib and I, I think the way we think of build is, you know,
we have a couple of places to announce the services and the products that we're working on
and kind of give our customers roadmaps and ideas of what to expect from our technologies
in the coming months and stuff like that. And so, you know, I hope that any developer
that watches this build this year, listens to this podcast, comes away going,
hey, I can see what cool enhancements are coming to .NET. And where the roadmap for .NET is heading,
where the future investments are going to be. And in the case of some of the Azure tech that we work on,
you know, what services are we building in Azure to handle your future compute loads
as you're thinking of moving to the cloud?
Do you find that with the .NET conference being, I think it was November last year,
and I think with the new November yearly cycle for the new versions of .NET, do you find that
whether .NET conference may have announcements or a new version of .NET's going live,
that there's a bit of a conflict with announcements for build versus announcements for .NET conference?
No, not really. You know, the way we kind of think of this is like .NET is supporting a
modern lifecycle policy, but you know, .NET as a product in itself, you know, sees its major releases
typically aligned with, you know, November timeframe, and that's when we end up doing .NET on.
But there are so many other pieces of technology, you know, whether it's, you know, our Azure platform,
you know, aspects, whether it is tools, where it's almost following an evergreen model these days.
So, you know, the team is working on so many things. So, it's not that, you know, we want to keep
all the announcements and do it just at the November timeframe. But as we keep adding more value
and keep building new things for our customers and developers, we just look at these as like, hey,
moments where we can share what we are building with the larger community, because, you know,
we are building a lot of these products along with the community. So, you know, that's one of the
things that we look at. So, it's not about just, you know, hey, it's, are we splitting those things,
et cetera. No, as we keep making progress, just use the moments to announce.
Yeah, it's very cool. There's so much stuff going on. So, we haven't actually yet spoken before the
recording about what the announcements are going to be. So, I'm a bit in the dark about what we're
going to cover in this episode. But I kind of feel that with .NET being open source, and both
.NET and Azure having very early previews, I can probably take an educated guess. So,
I'm assuming there's going to be quite a lot of Maui. Yes, one of the most exciting things
that we are announcing at Bill this year is the general availability of .NET Maui, or .NET Multi
Platform App UI framework. Now, as we know, there are a lot of desktop and mobile devices in the world,
you know, there are being more than a billion Windows devices and over 4 billion, you know,
regardless of whether somebody is a web developer or a native app developer,
you want to reach the most client devices possible with great user experiences in the most
efficient way possible. You know, in order to reach all these devices with beautiful app experiences,
we built .NET Maui, and you know, we are making it generally available at Bill. Now, .NET Maui
is the most productive way to develop native apps that perform great on any device that runs Android,
iOS, Mac OS, or Windows from a single code base. One of the biggest things for web developers
to see in this space is Maui also brings, you know, web and native together. So, you know,
you could use Blazor and Maui together in a single app to build the best of breed hybrid
applications across all of these devices as well. I think that's one thing I'm quite excited about
about just, well, just Maui before we talk about Blazor, just the fact that I believe this is like
taking over Xamarin, but then also introducing desktop apps and all this kind of thing.
And yeah, just being able to have cross platform desktop applications, because most of my work
is like web APIs and like web apps, that kind of thing. But I've doubled a bit with Xamarin,
and I've played a little bit with Maui, and just being able to reuse the same skillset to do
desktop apps, where in the past, I've used WPF and WinForms and things, but to do cross-platform
desktop apps, but also easily make those mobile apps at the same time, that is very appealing.
Yeah, no, that is correct. And you know, .NET Maui is really built on .NET 6. So, what that means
is you get a single unified .NET experience across your workloads and project types, right?
There is one base class library and unified type system with CLI support,
you know, that one could utilize. And under the hood, if you kind of think about .NET Maui
uses technologies that are out there today for building native apps on Windows with WinUI,
Mac Catalyst for Mac OS, and of course, you know, IOS and Android. Now, the good thing is,
.NET Maui essentially abstracts all these frameworks, you know, into a single framework
that is built on top of .NET 6, you know. And as we were talking about, .NET Maui lets web
developers build hybrid web apps as well. So, you know, you can share Blazor web components
directly with .NET Maui apps while having access to, you know, native device capabilities,
as well as packaging. And by using .NET Maui and Blazor together, developers can reuse one set
of web UI components across mobile, desktop and web. I think that is pretty powerful.
I want to double in and go, I'm also excited that there's a single project now too. So, it's like,
you take one of our new modern CS project files and all your assets, whether they're your icons
or your splash pages when you launch, all of that stuff in a single project is super excited to me
as somebody that when I first played with Xamarin in the past, I remember being confused by, wow,
there's an iOS app, there's an Android app, and there's a class library where you kind of
naturally infuse by having all this stuff in one single place. I think it just really,
really enhances the experience for building these mobile apps. Or, I'm not sure they're mobile
apps, they're cross device apps. Yeah, and I think apart from that single project that you could use,
you know, the one other amazing thing that Maui brings to the table or value prop that it brings
to the table is that, you know, APIs are available directly from C sharp to access over 60, you know,
device platform capabilities across, you know, variety of these devices, whether it's isolated
storage, sensors, dual lock, so on and so forth. So, it's all about, you know, the ease of getting
started, having a single project and the choice for developers, whether you want to build true
native apps, a mix of web and native with hybrid apps, etc.
We've spoken about using Blazor in Maui, but natively, it's still Xamal, if you're not using
Blazor, I believe. Is there scenarios where you would choose one over the other? Is it literally
just if your team has Blazor skill sets and doesn't want to learn Xamal? Or, is that what would
help you choose? I'll give you my example of this. There was a customer that we dealt with last year,
and they had a VB6 application, and they were going to move their VB6 application to,
they knew they needed to get off of that tech, that was, you know, that's deprecated tech. And,
as they thought about rebuilding it, they were going to rebuild it with web, because, hey,
it works on mobile devices, it works everywhere. But the problem was, they needed access to native
capabilities. So, for example, in their business, it was for stores, and so they needed the app to
be able to talk to displays on the wall. They needed the app to be able to talk to a cash register.
They needed the app to be able to talk to a control system inside of the building as well.
And, I mean, yeah, they could have probably gone and wired a bunch of IoT stuff to all that stuff.
But the easier way of doing that was actually, hey, if it actually runs to native app,
it has access to all the ports and cables and stuff that are plugged into the computer.
And so, that's one of the reasons you might build a hybrid application,
is because you're not just doing web, but you actually still want access to those native
capabilities of a platform. I mean, if you run an iOS device and you're running a web page inside
of that, yeah, JavaScript will give you access to some capabilities of the device, but a Maui hybrid
app will give you access to the whole device. And so, to me, that's one of those decision
factors you're making. Obviously, web is ubiquitous. It's easy to find web developers.
So, you might want to build a UI with the web, because that's easy.
You might still want those native capabilities, and that's why we would wrap it in a hybrid app.
Can you put, as well as blazer components, can you put other things within Maui?
So, I don't know whether I'm misremembering this, but I seem to remember hearing
things like being able to put within forms stuff in the web forms. Am I misremembering that?
The only web form stuff we did is Jeff Fritz on the team
has a series of blazer components that mimic some of the web form components.
So, we can find a link to that and add that to your podcast. But the intent there was,
you know, another cool part about blazer is, if you're a web form developer,
you're probably used to this control model with events that fire off the control model.
There's nothing that maps to that in ASP.NET core better than blazer does.
And so, if you're a web form developer and you're looking to, you know, move to the newer tech,
then blazer is kind of a natural feel. It feels very similar to web forms in the
indicted framework. And I said, Jeff Fritz has these cool tools that take about 15 or 20 of the
common controls you would have in web forms and makes them available in blazer.
Nice. I've got to say, I am a huge fan of blazer. And we're using it for quite a big project
at the moment. And it's just so productive. I think I love the component model of it.
So, everything's very reusable. And so, I've spoken a few times about blazer in this podcast.
And for me, I feel like the blazer wasm versus blazer server. Please correct me if I've got this
wrong, that I would tend to do blazer wasm for public facing applications, but then blazer server
for internal apps where it doesn't matter if you lose that persistent connection.
Is that what you would recommend?
Why do you think that? We'd be curious why you think that public facing things should be blazer
wasm? I guess it's because a public website, if someone's maybe traveling on a train or something,
maybe they're dropping it in out of connection, they might lose that persistent connection that's
required over the signal connection. But maybe that's less of an issue than I can assume.
I also guess it depends how busy the app is. Because the state is stored on the server side
and the DOM's managed on the server side, whether I can have wonder how scalable that is.
I believe it's quite scalable, but I guess less so than a wasm app.
As a long term web developer, I would, I find that most of our customers tend to want to lean
towards blazer wasm, but I think it's more because it's cool than it's the right solution for the
thing. I mean, if you're on a train and you have spotty web, then the web's not going to work
that well for you in any ways. So I don't think about the size of the connection. I was going to
say something even different. The cool thing about blazer server is there is no lighter weight
spa framework out there than blazer server. If you're building an angular react or a view
application, you're bringing a chunk of JavaScript down to the client. In the case of a blazer
server app, we're only bringing down like 100K of JavaScript. It's just enough JavaScript
to keep the signal art connection open and process the messages that come out of that.
So the other cool thing about blazer server to me is you have all of dotnet available to you.
Because you're running all of dotnet on the server, you can open up a database,
you can use a red as cash, you can do a variety of things because the entire platform's available
to you. As soon as you decide to go into a Wasm-based application, you're running in the sandbox
inside of the browser. And so you lose access to a bunch of those capabilities that you would
normally not have. I tend to think that the best use cases for like a blazer Wasm application are
I need a web application that needs to be disconnected. Or I need an application that
wants to write natively to the screen. If you really want to do high performance drawing and
stuff like that, then that's going to be a better story for you because you are running in the browser
versus rendering HTML from the back. But really it's those disconnected
kind of feel like a real app kind of models where I think it fits more.
But I do think we all kind of geek out, even I geek out. I was talking to some people this morning
and showing some of the cool stuff where you can run SQLite.
There's a flavor of SQLite that now runs in Wasm. And I will be honest with you,
I geek out and I'm like, wow, that's amazing. I don't know if it's what I should do.
I geek out. It definitely gets you that portability as well,
right, that you are trying to achieve.
You can never have too much geeking out anyway, it's all good.
One thing I do like about the blazer server side then is from the productivity aspect.
So as you mentioned, you've got access to all.net and entity framework.
You can access your database straight away. Well, I guess in Blazer Wasm,
it is a spire up and you've got to treat it like AngularView React.
And server side, you need APIs.
So then you've got to deal with authentication and all this kind of stuff.
But with Blazer server, your code can talk straight to the database,
have connection strings, use configuration.
So from a productivity point of view, yeah, I don't think you can beat Blazer server.
Yeah, you call it productivity, but I think just to add on what Scott was saying,
I think it's really about what you are trying to build, right?
I think if it is a single page app pretty well contained,
the Bazaar model might work well for you.
But if you really want to utilize all the power of .net,
you know, have those different, like whether it is database access
or any other thing that you want to run, like, you know,
one of the things I was talking to somebody recently is like,
yeah, I want to run some AI models on the back end.
Can I access it with, you know, yes,
you will have the power to access them on the server side
and, you know, bring down any of that content to render into the web client as well.
So Blazer is already live and you can use it in production and everything.
Are there any Blazer related announcements coming as part of build?
I think the biggest aspect for Blazer that we are announcing at build
is really that, you know, we are bringing Blazer forward
into Mavi apps as well to enable those capabilities.
That's I think the biggest one coming for Blazer.
But yes, in general, you know, again, in terms of the enhancements,
we keep looking at multiple things that are evolving in the Vasem space.
There is .NET on Vazi, which is like, you know,
this is an experimental thing that we've been working on,
is like, you know, Vazi is a standard for running web assembly on the server.
And, you know, the question that we had was like,
can we extend .NET browser based to a VasemTech to run on Vazi?
So one of the experiments that we ran recently was,
you know, can we run all of ASV.NET core on Vazi?
And, you know, we have been able to do that in an experimental form,
so which is great.
So I think no other big announcements coming for Blazer,
other than the fact that, yes, Blazer is a tech that,
you know, is available with Mavi as well.
It's funny, I haven't actually heard of Vazi,
so I feel I should have done.
Yeah, so Vazi is basically, you know, it's essentially a new standard
that is, you know, sort of forming.
And it's all about running web assembly on the server, right?
It provides OS like capabilities, you know,
whether it's like things like, you know, access to the disk
or the network, while keeping the sandboxing,
you know, portability as well as the speed of web assembly.
Some of the use cases here are really things like,
you know, whether it's cloud, your Edge apps,
you know, whether it's IoT and hosting,
you know, think about secure multi-tenancy
or semi-trusted plugins, etc.
It is still, you know, quite early.
So it's an unproven technology.
But yeah, it's something where we geek out
and, you know, we feel that it has a potential
to be a significant industry-wide shift that it can bring.
Well, that's what happened to Blazor.
It was kind of, when it first started,
it felt like that kind of new thing that would never,
well, not never, but maybe not catch on.
And now it's huge.
It's kind of, I know lots of companies
that are doing Blazor apps.
And that's how a lot of these big things start.
It starts at something which was just an idea
and then it becomes a huge thing.
Yeah, and I think that's true.
And for .NET, you know, we always love to keep playing,
love to keep experimenting with the cutting edge,
you know, so to make sure that, you know,
we can take the .NET developers
anywhere where the industry is going forward, right?
So some of these are very, very early.
But yeah, no, it's exciting for sure.
Yeah, that's what I love about .NET,
with all the new releases.
I'm a big fan of the way C-Sharp is becoming much more functional.
Because I just like having my code really succinct
and small and functional.
And it's just becoming easier and easier and easier to do that.
Yeah, so huge, huge fun.
With Blazor, I know there's all the AOT stuff.
Is that changing in .NET 7?
Is that improving?
How does that work?
With .NET, there are really three core pillars
that we build .NET on.
I think the first one is performance.
The next one is simplicity.
And the third one is ubiquitry or being everywhere.
And what you touched upon is the first pillar
around performance.
One of the things that we keep working on
with every release of .NET
is we want to make it go faster and faster.
Of course, in terms of AOT,
we are going to be making progress.
But even if you look back at the .NET 6 release,
we did a blog post where Stephen Thope from the team,
he did a 30 plus page blog post
about how we are improving the performance of .NET.
So yes, I think with every release,
there are enhancements.
We are still continuing to push the boundaries
with the AOT support for Blazor as well.
So there will be enhancements
that are surely coming in the area.
So am I right that when doing AOT,
whilst it's increasing the performance,
it'll also increase the size
that gets downloaded to the browser?
That is correct.
So I think one of the things AOT
gives you faster startup,
but it comes at the cost of higher
footprint initially,
or memory footprint initially.
It's one of the things
that we also keep paying close attention to
to see how we could bring
the best of both worlds
without bringing a lot of overhead.
But yes, for developers,
that's a balance that you would have to achieve
because I think while AOT helps provide
much faster startup time,
it does come at a cost of a heavier memory footprint.
And can you combine that with,
I'm going to use the term tree shaking,
but I believe you use another term.
Can you combine that to actually reduce the size a bit?
We're already doing the tree shaking
in the Blazor apps already.
That's one of the ways
that we actually make sure
we don't bring a crazy amount of stuff down.
And that tree shaking got better in .NET 6.
So if you look at a Blazor Wasm app
from .NET 5 to .NET 6,
you'll see a pretty significant decrease in size.
Another aspect to what Tegarev was saying
is I hope that in the future,
right now, if you throw the AOT switch on
in a Blazor Wasm app,
we AOT your entire application.
I'd love to get to a point
where you basically put an attribute
or some kind of designator
on the code that you want AOT.
Because what I really want,
I might have some graphics worked,
I'm painting on the screen
and that's really important for that to go fast,
but the rest of it, I don't care.
And so hopefully in maybe seven
or sometime down the line,
we give you more controls
so you can decide how much code for us
to actually AOT versus how much
do we interpret in the browser.
That makes total sense.
And presumably you've got some form of caching
with files being downloaded anyway,
so it's not like every time you go to a page,
you're downloading all that every single time.
That's just part of PWA.
I think the manifest file
that is part of a PWA application
kind of tells the browser,
hey, you should cache this stuff.
So you pay the cost once and...
This is random, but it's talking about size
and performance and stuff.
One of the things that really excites me
about Blazor, and we've had this for a bit,
is we do have the ability to prerender
the first version of the page on the server,
which is probably one of my favorite
Blazor features, because how many of us hit websites?
I was hitting a third party conference website
just yesterday, and he hit the web page
and the page is a blank page
with a spinning circle in the middle of it.
And I know Dan Roth on Garvis Team
has done plenty of demos
where he basically shows
you can build a fairly cool Blazor application,
even in Wasm, and have those first pages
just load up instantaneously.
And I know in six,
we actually even take the state from the prerender,
and it's available to the app
after the app renders that first page,
and so it doesn't have to do any more work
on the next request either.
And so that's the kind of cool tech
I think of when I think of Blazor and performance,
and as I said, I hate seeing
spinning circles or empty web pages,
and it seems to be the norm today on the web.
You go to all these pages
and they just load really slow.
Yeah, definitely.
Am I right that that's restricted
to the hosting model?
So if you're putting a Blazor Wasm app
in some static storage, like blob storage,
you can't do that in that case,
you could actually host it Blazor
in something like ASP.NET Core.
I don't know.
I think it still works in static storage,
static storage as well,
parce que typiquement,
le premier page de l'app
ne sait pas vraiment qui vous êtes,
ou je pense que ça pourrait
de nouveau dépendre de l'app.
Si l'app est en train de dire
que je vais en faire de cette façon,
si vous êtes dans ce pays,
ou quelque chose comme ça,
peut-être que vous n'aurez pas pu
utiliser cette capacité,
ou que vous devez faire de l'exemple
pour faire la capacité.
Mais les pages de web ne savent pas
beaucoup de vous en le premier request.
Presumement ça va vraiment
aider le SEO
et ce genre de choses.
Ça peut.
Oui.
C'est le plus grand challenge,
je pense,
parce que le web de la web,
si vous l'avez fait,
si vous vous buildez une
moderne app,
client, client,
c'est que si vous avez tout le temps
rendu sur le client,
il n'y a pas de
search engine pour vous,
quand vous faites les pages.
Oui, exactement.
C'est une chose que je suis toujours
en train de savoir,
pas juste Blazor,
mais si c'est Blazor,
Angular, Vue React,
ou quelque chose,
c'est,
comment ça s'efface, SEO.
Et nous supportons le model de hybrid
où vous pouvez en fait
avoir des pages de la page
dans un app de Blazor,
aussi.
Vous pouvez avoir un mix de la
client-stuff
et un mix de la service-stuff,
parce que,
pour le moment,
c'est une de mes péts-pives,
c'est que
nous nous avons overdue
les choses clientales,
comme on l'a parlé de Wasm
plus tard,
les gens de web-developpages
aujourd'hui
nous nous overdue,
il n'y avait pas de
service-rendue sur les pages.
En beaucoup de cas,
ils sont
juste comme bon ou mieux,
et vous ne faites pas
vraiment un
improvement
sur la expérience de la web
par tenter de le faire
tout en train de le faire.
Et donc,
je ne sais pas si Garh
se le fait de cette façon.
Je pense que Garh,
il a,
je vais le faire,
il a été le plus
en train de travailler
sur la team de la salle,
donc,
il est un
web-developpage
de la fin à la fin aussi.
Donc,
je veux entendre vos conseils, Garh,
de ce que vous pensez
sur l'adaptation de client-stuff,
et des choses comme ça.
Oui, je pense que c'est...
Non, merci, merci, Scott.
Merci pour le faire,
mon background.
Donc, oui,
je suis assez nouveau
à la site.
Et, vous savez,
dans l'arrière,
j'ai spenti
beaucoup, beaucoup de années
en travaillant sur
la web,
et la plateforme web,
les langues, etc.
Je pense que c'est vraiment un mix,
et c'est dépendant
de l'utilisation que vous voulez essayer.
Comme je pense,
encore, comme nous l'avons dit,
quand vous êtes sur le client,
vous êtes assez resté
à un sandbox,
et vous devez faire sure
que vous êtes délivré
d'une expérience très optimiste
dans ce sandbox.
Vous savez,
si vous avez besoin
de places où
il y a un niveau très haut
d'interactivité,
vous avez besoin de
très riche access.
Beaucoup de fois,
vous savez,
je vois des choses
envers les services,
même les services de services,
comme exemple,
et puis, vous savez,
juste de la streamer
sur le browser.
Et c'est un des battles
que je pense que dans les derniers 20 ans,
je n'ai pas vu une technologie
dans l'envers,
vous savez,
c'est toujours comme
chaque côté
s'occupe de voir
comme,
hey,
lequel est-il mieux
et il y a
le bon chose,
c'est que,
vous savez,
pour les développeurs
et pour les utilisateurs,
ce qui signifie
que, vous savez,
nous nous continuons à improving
en termes de
les technologies
et nous continuons à evolver.
Donc,
je pense que pour les développeurs,
en général,
c'est vraiment
dépendant de vos scénarios.
Il n'y a pas de
une certaine
guide que j'ai vu,
c'est comme,

vous faites X,
vous êtes client,
vous faites Y,
vous êtes service.
C'est vraiment comme,
vous savez,
vous devez penser
sur votre scénario,
comment cela optimise,
quelle dépendance
cela a-t-il?
Est-ce que ça va être super chat,
etc.
Et puis,
ça va être de là-bas.
Cela me rend vraiment partie
de la conversation
dans l'an dernier,
j'ai eu Andrew Locke
sur le show
et nous en parlons
sur
www.asp.netcorps

les pages Razor
et la laser
et,
c'est assez bien,
il est un grand fan
de la service,
il a un livre sur www.asp.netcorps
où il parle beaucoup
de pages Razor
et il a dit exactement
ce que vous avez juste dit
sur
ne pas oublier
la service,
c'est encore un truc
et,
comme vous l'avez dit,
c'est comme,
c'est cool et nouveau
et chineux
et les gens veulent
se gérer.
Donc,
je pense que l'important est
que les développeurs
comprennent
toutes les différentes options
et faire une décision
sur quoi
d'autres technologies
vont être choisis
parce qu'ils vont probablement
être restés avec la tech
pour les prochaines années
pour ce projet.
Oui,
non,
et je pense que
ce petit petit petit truc
que je vais ajouter
comme un bloc
est
c'est assez excité
d'être probablement
le seul runtime
au sein de la vm JavaScript
qui apporte
Basm
aujourd'hui,
je veux dire,
c'est incroyable,
c'est incroyable,
c'est tout en
en train de apprendre
et c'est en evolvant
mais
c'est assez incroyable
d'avoir
un runtime
qui apporte
Basm
au sein de
aucune vm JavaScript
donc,
c'est très bon
j'ai hâte de voir ça
comme de la team
Les écoutes ne peuvent pas voir
mais je peux voir
vos livres
en train de se faire
vraiment exciter
dans le webcam
donc
ça montre
comment
les gifteurs
et les nouveaux et les charniers
c'est bien
c'est une chose
que j'aimerais juste
aimer
dans cette industrie
il y a
beaucoup de cool choses
pour apprendre
et jouer avec
Juste pour l'adverter,
je pense que
partie de cela
c'est de la preuve
que la preuve
est prête pour
quelque chose
de la prochaine génération
de choses qui se passe
dans l'industrie
et donc
nous voulons
faire surement
que l'avenir
soit prête pour ça
vous ne voulez pas
être surpris
et puis
deux ou trois ans
derrière
ce sont les inspirations
de faire
des choses
de l'asem
et
il y a d'autres choses
aussi
comme
le dotnet 6
a pu
avec une prévue
de l'HTB3
qui aussi
va montrer
que
le dotnet
est en train de rester
sur la plage
même si
l'HTB3
n'est pas
prête
c'est
vous savez
que quand c'est prête
le dotnet
va être là
à l'arrivée
parce que nous avons
déjà
une prévue
d'infligmentation
de la plage
aujourd'hui
et c'est
comme
je pense que
le dotnet
on toujours
essayant
de rester
sur la plage
donc
vous avez
les nouvelles
capacités
quand elles vont
sortir
et presumably
ça va
se faire
bien
dans
ce qui est
fait
dans l'Azure 2
c'est
en fait
un
chose
je veux dire
il y a
un
des features
que nous avons
dans le dotnet
c'est le GRPC
et vous trouverez
qu'il y a plein de parts
d'Azure
où le GRPC
ne marche
le manière
que vous voulez
je ne pense pas
que les raisons
sont pour ça
c'est
un des
des
des
des
des







des
des

des
des

des

des

des

des


des
des



des
des

des






des




des
des







des

des
des
des
des
des


des
des

des
des
des
des
des





des
des
des
des
des
des
des
des
des
des
des
des
des
des
des

des
et Azure, on va avoir HB3 au jour 0.
Vous verrez que l'app service est dans le processus
de faire de l'app en fonction de l'app
et quand ça arrive,
vous allez avoir toutes les outils les plus vides
comme le GRPC,
disponibles nativement en app service.
C'est un grand request que nous avons à l'heure.
Il y a des hacks que les gens peuvent utiliser aujourd'hui.
Il y a un grand package que la team de GARRAVE
donne à vous de vous faire gérer le web.
Ça peut être un travail pour faire l'app service aujourd'hui,
mais c'est cool de voir que les parts d'Azure
utilisent un VIRTEC
pour faire sure que,
en tant que OS,
ou les versions de OS,
ils peuvent appliquer les nouvelles capacités de la web
pour les services dans Azure.
C'est très cool.
J'ai vu les annonces de YARP.
Je pense que c'était la dernière semaine
où il y avait une nouvelle version.
Je n'ai pas joué avec ça,
mais j'espère vraiment,
parce que j'ai utilisé l'enginé un peu,
et les fesses de la config n'ont pas le meilleur.
J'espère que, en passant au TR,
ce sera un peu plus facile de l'utiliser.
C'est juste un des choses qui sont sur mon long liste
de choses à jouer avec.
En parlant des files de config,
c'est un grand exemple de ce qu'est un espace d'emburgage
ou d'assemblage de web,
que ce soit l'Ingenax ou YARP,
ou un nombre d'autres solutions qui sont là-bas,
pour beaucoup de choses.
Dans beaucoup de cas,
vous devez coder les règles pour ces choses
dans le langage que vous avez,
peut-être un JavaScript,
que ce soit en cas de YARP,
ou de PCSharp,
ou d'Ingenax, ou d'autres choses.
C'est là que l'assemblage de web est,
c'est même au sein d'un .NET,
que vous pouvez l'innover.NET.
Le tech de WebAssembly est un cool tech,
car ça signifie que vous pouvez utiliser de l'anglais.
Imaginez que si vos règles sont en WebAssembly,
alors que, par contre,
c'est un langage agnostic,
et vous pouvez écrire les règles
dans lesquels vous avez le plus confortable.
Et donc,
ceci, pour moi, est une partie d'emburgage de tech
qui est allée en place,
où les choses comme WebAssembly,
je pense que le terme qu'on utilise,
est de democratiser
le moyen de faire ces choses.
C'est cool.
C'est un point de vue qui est très important,

utiliser les règles de WebAssembly,
et vous pouvez écrire les règles
dans lesquelles vous avez le plus confortable
pour votre proche de l'art.
Je veux dire,
nous avons le droit de faire ce type de choses,
je ne sais pas si c'est pour l'investissement,
mais si le marché voulait aller à ces places,
nous avons le droit de faire ça.
WebAssembly est le nouveau assemblage.
Donc, on a mentionné la reload,
très rapidement.
Je ne sais pas si c'est déjà là-bas,
mais j'ai certainement trouvé des instances où
ce n'est pas rechargé,
que je ne l'avais pas prévu.
Et je crois que les nouvelles versions de WebAssembly
sont en fait en train d'improver.
Est-ce que c'est quelque chose que nous avons à attendre
pour WebAssembly 7,
ou est-ce que c'est quelque chose qui va venir bientôt?
Je pense que dans le cadre de la reload,
il y a un peu de scénarios que nous sommes réveillés,
qu'on ne travaille pas mal avec WebAssembly 6,
mais le but c'est de faire surement
que nous ayons la valeur
pour les développeurs,
comme nous l'avons appris.
Il y a sûrement des zones que nous continuons
à improving sur leur support,
et comment nous pouvons
faire de plus de support
dans les scénarios,
avec, bien sûr,
WebAssembly,
WebAssembly 7, etc.
Donc, vous devez continuer de voir
l'imprové de la support
dans ces scénarios
pour continuer à progresser.
C'est certainement juste de avoir
ce bout de développement short,
donc je peux tendre à avoir
ma IDE sur une main,
et les browsers sur l'autre,
et juste de pouvoir changer le code,
et, comme je le change,
je le vois apparaître.
Maintenant, si je pense à
quand j'ai commencé à développer
les formes de Web,
et je fais un change,
et vous devez attendre un moment,
je sais que ça a,
quand j'ai tendu à avoir
une CMS sur le top,
donc ça pourrait être
plus ou moins slow,
mais juste de faire un peu de minutes
pour chaque changement,
pour la productivité,
c'est juste un killur.
Et la différence
au reload,
où vous avez juste de la feedback immédiate,
c'est un bon jour.
Oui, et je pense que
le truc que j'avais à dire
c'est que, quand vous vous parlez de ça,
on a vu la
bonheur sur votre face,
parce que la vignette productive,
la vignette productivité,
cette plus rapide,
pour aucun développeur,
c'est un truc important
pour en faire un improvement.
Parce que c'est l'une des choses,
si vous commencez rapidement
à ajouter tout le temps
que vous vous investissez
en building, en relanchant,
et en tentant de voir
les changements que vous avez
faits,
qui ont aidé l'app
dans la bonne façon ou pas,
c'est une grande productivité
quand vous commencez à ajouter
tous ces minutes
et heures
que les développeurs
ont à payer sur ces sortes
d'activités
sur un basis de jour-à-day.
Donc, plus d'un,
j'adore la gaine productivité
que ça donne.
En parlant de la bonheur sur ma face,
beaucoup de les listeners
savent que je suis un grand,
grand fan de Kubernetes.
Et c'est...
Je pense que vous avez déjà parlé
de ça avant,
mais il y a un nouveau truc
dans Azure called Azure Container Ops,
qui me confère,
j'utilise l'AKS
beaucoup dans Azure,
et je n'ai pas joué
avec Azure Container Ops,
qui est...
comme moi,
parce que c'est construit
sur Kubernetes,
donc je devrais l'avoir joué
avec ça par là,
mais je n'ai pas encore.
On peut parler un peu
de Azure Container Ops?
Bien sûr.
Azure Container Ops
est quelque chose que nous avons
créé et construit,
et donc c'est maintenant
généralement disponible
pour quelqu'un qui veut
utiliser,
c'est comme il y a été
avant.
Et la réplique de container
Ops est assez simple.
Il y a un peu de choses,
je pense que nous tous savent
que,
au moins je me sens
de cette façon,
nous sommes dans un mode
où le container
s'est rendu comme
l'asset public que nous faisons.
Il y a été dans le passé,
vous pouvez publier
votre code source,
ou vous pouvez publier
les propres compagnies
de votre application,
et maintenant,
les uns des uns
sont publier
les containers à la cloud.
Et l'idée
derrière container Ops
est,
en fait,
nous savons que
la Kubernetes
est super cool.
Ce qui fait que la Kubernetes
est super cool,
c'est que c'est un cloud
et une compagnie
neutrale,
ce qui signifie
que ce n'est pas
un bias avec ça,
pour le plus grand.
Mais,
comme quelqu'un
qui a des groupes
de toutes les plateformes passées,
Azure Functions,
Azure App Service,
nous savons aussi
qu'il y a plein de gens
qui veulent faire des containers,
et qui veulent faire des Kubernetes,
mais qui ne veulent pas
y faire les Kubernetes.
Et donc,
pensez sur les apps Azure container
comme un moyen de
faire vos containers
sur les Kubernetes,
mais nous sommes
menacés dans la cluster
de Kubernetes
sous la couverteur.
Vous avez encore
toutes les features de la scalability
que vous voulez,
donc vous pouvez
scale-en,
scale-en,
scale-en,
et scale-en.
Vous avez de l'aide
pour plusieurs versions
et des revisions
de les applications.
Il y a un ton de
des features
dans ces applications.
Et ça ajoute
les quelques choses
que nos plateformes passées
ne sont pas souhaitées.
Alors,
si vous avez un service
de la plateforme Azure
et vous avez une function
Azure,
bien,
ces deux sources
Azure
sont des nôtres.
Et si vous voulez
mettre ces nôtres
sur la même chaine,
vous devez au premier
mousqu'un,
vous devez créer
une chaine virtual.
Un peu plus de travail pour vous.
On a des choses cool pour Azure Container Apps,
c'est que nous sommes en train de faire un cluster de Kubernetes pour vous.
Vous pouvez faire 3 ou 4 containers en ce moment,
si vous voulez, et ils sont tous en même métier.
Si vous n'avez pas de créativité ou de paix pour la version premium,
des skeus et tout comme ça.
Nous sommes super excitées de dire que si vous voulez
manager Kubernetes, vous pouvez faire AKS.
Si vous voulez faire des containers et ne devrez pas,
vous pouvez faire Azure Container Apps.
Nous avons des customers qui sont dans les spectraux.
Certains sont dans les deux produits.
L'un des choses que nous voulons faire c'est
qu'aujourd'hui, on a l'air de choisir la porte A ou la porte B.
Si vous voulez utiliser l'app service ou l'app AKS,
si vous n'avez pas de la paix,
ce n'est pas facile de faire dans l'autre porte.
L'un des goals avec Azure Container Apps
est de faire ça très simple.
Vous avez un container dans les Kubernetes,
l'AKS, que vous voulez faire dans les containers?
Oui, vous pouvez faire ça.
Vous avez un container dans les containers?
Vous voulez changer l'app AKS?
Nous voulons faire ça comme si vous n'avez pas fait une décision.
Vous pouvez dire que vous avez des parts dans les app.
Je ne dois pas les manager un peu.
Je vais les faire dans les containers Azure.
Cet app, je vais les manager tout à moi-même.
Je vais avoir mon ops-team.
Nous voulons donner vous toutes ces flexibilités.
C'est notre but.
C'est de vous donner un grand spectre d'élection et de contrôle
tout de l'app service, si vous voulez nous dégager
le temps de tour, le système d'opérance,
les containers Azure,
les containers au top des Kubernetes
sans manager les Kubernetes.
L'AKS vous donne un plein de management,
un plein de contrôle de tout.
Je pense que ça fait notre cloud de gris
de vous donner ce plein de souhaits
en dessous du contrôle que vous voulez.
Je pense que même avec AKS,
parce que les nôtre pools,
les VMs sont créés par Azure,
il y a encore un instant de management.
Ce n'est pas comme si vous avez un cluster de management.
Je ne recommande pas à personne d'aider,
si il y avait un on-premise,
il y avait des options de management.
Mais pour créer un cluster AKS,
c'est vraiment facile à faire.
Et...
OK, vous devez faire plus pour vous-même.
Vous devez comprendre plus.
Vous devez faire plus pour vous-même.
Vous devez comprendre plus.

Vous devez comprendre plus.
Vous devez comprendre plus.














Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.






















Vous devez comprendre plus.
Vous devez comprendre plus.













Vous devez comprendre plus.









Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.

Vous devez comprendre plus.





Vous devez comprendre plus.
Vous devez comprendre plus.


Vous devez comprendre plus.
Vous devez comprendre plus.






Vous devez comprendre plus.
Vous devez comprendre plus.

Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.











Vous devez comprendre plus.













Vous devez comprendre plus.
Vous devez comprendre plus.

























Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.







Vous devez comprendre plus.
Vous devez comprendre plus.


Vous devez comprendre plus.




Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
























Vous devez comprendre plus.
Vous devez comprendre plus.


























Vous devez comprendre plus.
Vous devez comprendre plus.




















Vous devez comprendre plus.




Vous devez comprendre plus.
Vous devez comprendre plus.






Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.











Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.







Vous devez comprendre plus.
Vous devez comprendre plus.


Vous devez comprendre plus.









Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.





















Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.













Vous devez comprendre plus.
Vous devez comprendre plus.



Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.








Vous devez comprendre plus.
















Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.




Vous devez comprendre plus.


Vous devez comprendre plus.




Vous devez comprendre plus.

Vous devez comprendre plus.
Vous devez comprendre plus.

Vous devez comprendre plus.

Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.




















Vous devez comprendre plus.

Vous devez comprendre plus.

Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.























Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.

























Vous devez comprendre plus.
Vous devez comprendre plus.






Vous devez comprendre plus.


Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.

Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.








Vous devez comprendre plus.

Vous devez comprendre plus.


Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.



Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.














Vous devez comprendre plus.








Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.






















Vous devez comprendre plus.

Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.

























Vous devez comprendre plus.
Vous devez comprendre plus.


Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.

Vous devez comprendre plus.









Vous devez comprendre plus.

Vous devez comprendre plus.
Vous devez comprendre plus.



Vous devez comprendre plus.












Vous devez comprendre plus.


Vous devez comprendre plus.
Vous devez comprendre plus.


Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.








Vous devez comprendre plus.
Vous devez comprendre plus.


Vous devez comprendre plus.









Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.


















Vous devez comprendre plus.

Vous devez comprendre plus.




Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.










Vous devez comprendre plus.













Vous devez comprendre plus.
Vous devez comprendre plus.


























Vous devez comprendre plus.















Vous devez comprendre plus.








Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.








Vous devez comprendre plus.


Vous devez comprendre plus.







Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.










Vous devez comprendre plus.











Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
























Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.



Vous devez comprendre plus.












Vous devez comprendre plus.

Vous devez comprendre plus.

Vous devez comprendre plus.


Vous devez comprendre plus.

Vous devez comprendre plus.


























Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.







Vous devez comprendre plus.


Vous devez comprendre plus.


Vous devez comprendre plus.
Vous devez comprendre plus.






Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.


Vous devez comprendre plus.





















Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.



Vous devez comprendre plus.




















Vous devez comprendre plus.
Vous devez comprendre plus.









Vous devez comprendre plus.

Vous devez comprendre plus.





Vous devez comprendre plus.







Vous devez comprendre plus.
Vous devez comprendre plus.














Vous devez comprendre plus.














Vous devez comprendre plus.
Vous devez comprendre plus.


























Vous devez comprendre plus.


















Vous devez comprendre plus.







Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.




















Vous devez comprendre plus.

Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.

















Vous devez comprendre plus.






Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.











Vous devez comprendre plus.

Vous devez comprendre plus.











Vous devez comprendre plus.














Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.




















Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.

























Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.






















Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.


























Vous devez comprendre plus.
Vous devez comprendre plus.
























Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.











Vous devez comprendre plus.
Vous devez comprendre plus.




Vous devez comprendre plus.







Vous devez comprendre plus.
Vous devez comprendre plus.



Vous devez comprendre plus.

Vous devez comprendre plus.

Vous devez comprendre plus.



Vous devez comprendre plus.
Vous devez comprendre plus.











Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.
Vous devez comprendre plus.