Blazor WebAssembly, Blazor Server,
Blazor United, Blazor Mobile Bindings, Blazor Hybrid... There is a Blazor for everyone.
So there is a Blazor for you! but with all these different things
called Blazor, it might get a little bit confusing. So in this video, we're
going to explore what these different blazers are and which one is the perfect one
for you. Let's start at the very beginning.
What is Blazor? At its core, Blazor is a single page application
development framework built by Microsoft based on C# and .NET. And you
can use HTML and CSS to compose your views. But
typically when you think about single page application frameworks or SPAs, then
you think about Vue or React or Angular or all those frameworks which
are based on JavaScript. And the best thing about Blazor is
that you don't have to write a single line of JavaScript, ever. Woohoo. Now
this is not about making fun of JavaScript or any other
language for that matter. But the fact is that if you have to switch context between
the language that you use daily, C# and some other language TypeScript,
JavaScript or whatever, it's going to eat into your
productivity, right? You have to switch context. How do you
do that thing again? And that's just not great. And that's where Blazor
comes in. With Blazor, you can stay inside of your C# and .NET
ecosystem, use all the tools that you love and
are familiar with Visual Studio NuGet, and you can keep writing C#
code for all the things that you want to do inside of that single
page application. A little fun fact before we dive into the first Blazor flavor
Blazor WebAssembly, did you know that Blazor is a combination of two
words? Do you know which ones? No. Browser and Razor. So you probably
know what a browser is, right? You're probably
using it to watch this video right now. And Razor is the technique
that is used to render views. But on the server side,
when you're using ASP.NET and Blazor is part of the
ASP.NET family. But now these views are rendered also on the client
side. That is one of the first differences between
Blazor. So they put these words together and now we have Blazor, which is kind
of funny because technically it should be Brazor... Anyway, let's
dive into Blazor WebAssembly. Blazor WebAssembly together with
Blazor Server were kind of like the two first flavors of Blazor that were
introduced. And Blazor WebAssembly is especially cool because that is very
similar to how JavaScript applications work right now because all the code is
executed on the client. Blazor WebAssembly
uses err... WebAssembly, and WebAssembly is often abbreviated,
as WASM. WASM, which is basically an
instruction set that can be used to be interpreted by the host that it
runs on, or it can even be used to compile to machine readable
code. And it's not a technique that is specific to
Blazor, it's not even invented by Microsoft. It's an existing technology
that is already out there. And the way it actually works is very
similar to how Net works or how Java works. If you're coming from
the Java world because you have this high level language like C# or Java that
gets compiled into a kind of like intermediate
language and that is then run on the host, basically. So in this
case, you can also have this higher level language, C#, which is then
interpreted, compiled into WebAssembly and then run on the client's machine.
And because WebAssembly is an existing technology that has been out there for
a while, it's now supported by all modern browsers on iOS, Android
Windows, macOS, Chrome, Safari, Edge, Firefox.
Doesn't really matter! It's supported on all these modern
version browsers. So just install that and you can run WebAssembly things. So the
only thing that Microsoft basically did is create a compiler
that takes C# code, turns that into WebAssembly, and
suddenly you can run inside of all those browsers. And by doing that,
you suddenly have a technique that is very similar to JavaScript. All the
code is executed on the client. And we can make this rich experience
single page applications by just using C#. So what are the things that
you want to take into consideration when you're going to work with Blazor
WebAssembly? Because you're going to download the full application to your
client? There is a couple of things to be mindful of. First, the
performance is probably going to be good, right, depending on the client. There
can be a thin client with lower specs that will make the performance
not great, but typically, it will be a powerful machine, a powerful mobile
device that you can run your application on. And there's no going
back and forth between a server for all the interactions. Besides
maybe some rest APIs that you want to call into. But otherwise, everything runs
on the device, on the client. So the performance should typically be pretty
good. Also because of that, this allows you to create offline
applications. After that initial download, you can maybe build it as a
progressive web app. That's definitely an option as well, where it's just
installed on the user's phone and it can be accessed as an offline application
and be used anywhere, which is something, obviously, that
you have to take into account when building your application that it can be
offline. But you can build offline applications this way because the application lives
and runs on your client. But then there's the other side of
things. The application is downloaded in full to your client, which is the thing
that I just said. But this can also be a downside, right? Because you
don't only have to download your whole application, but your
application runs on a specific version of the net runtime. And we don't have
net runtimes installed on our machine anymore. We deliver that
together with our application. So the net runtime that you're using
for your application is being downloaded together with your whole
application onto the client. Now that might sound like a lot, but
for modern .NET versions, the .NET runtime is like less than a megabyte. So
that's like less than your average cat gif. Jif? Gif? Jif? What's your team
let me know down in the comments. That's going to be less
than your average image on the internet, but it's still something that you want
to be mindful of whenever you're building applications that might be important
in certain areas in the world where bandwidth is not
widely available or where it's very expensive. Right? And
of course the initial load time is going to go up as well because the
application has to be downloaded in full before you can actually start
working with it. And one more thing in terms of security, again, you're
downloading the whole application to the client. So if you have some exciting
super secret business logic inside of your application, they have
the DLLs that have the code in there so they could decompile it, they
could maybe look into it. So that's something to take into consideration
as well and something that is not possible with our next flavor, which is Blazor
Server. Blazor Server is more of your traditional approach,
if you will. Your application runs on a server, probably in the cloud. All
your application logic, all your business logic is going to be
safely living there. So the thing that I just mentioned about security
doesn't apply here. The only thing that gets sent to the client is the changes in
HTML. So the rendered stuff basically. And because it's a
single page application, it's only going to replace the things in the browser that
it actually has to. So that's also, again, kind of the
downside. There is a constant persistent signal arc connection
between the server and the client going back and forth with each click
that they do, determining what is going to be the
change in UI and that's going to be pushed back to the client. So there is
no offline capabilities with this. You have to
have this constant connection. You will have your code more secure
over there. It is much more lightweight on the client. So if
you're working with thin clients, if your clients are not very powerful, then
this is probably the way to go. There's no heavy processing on the client side
going on and you can do all the heavy processing in the server. So
this is more your traditional approach, but now encapsulated in this single
page application framework and still built with C# and net. Then
after Blazor WebAssembly and Blazor Server, we got Blazor
Hybrid or .NET MAUI Blazor, or it has a couple of
different names, but Blazor Hybrid is the thing that we'd landed on mostly, I think.
And Blazor hybrid is super exciting. It doesn't really have
anything to do with using WebAssembly or using Server, but it has everything
to do with running a Blazor application directly
on the client machine. Blazor Hybrid is a technology that
shares a lot of the concepts with the other Blazor flavors that we've just
mentioned. But in terms of hosting, it is completely different. There is
no web host that it's running on, there is no WebAssembly that we're compiling to
because remember, Blazor is just another .NET
application. So it can run directly on the .NET runtime,
and we have the .NET runtime running through .NET MAUI
on iOS, on Android, on Windows, on macOS, on
Tizen. So suddenly we have this Blazor Hybrid application
that we can run on all these platforms natively.
.NET stands for .NET Multi-platform App UI. And that is Microsoft solution
for building cross platform apps based on C# and .NET. Now, if we
combine that with the power of Blazor, we suddenly have this crazy
powerful solution which will allow you to take your existing
Blazor application or maybe your reusable Blazor components that you might have
been working on and reuse those inside of a native mobile client application,
or not even mobile. You can also run it on desktop
and you can leverage all the power of the client that you're running on.
You will have full control, full power over the Windows machine that you're
running on, over the iOS device that you're running on. Basically the only thing
that you're doing is replacing the UI, the native UI on that platform,
which is one of the strengths of .NET MAUI, but you're replacing that
with a web UI. So you're replacing that with HTML and CSS
with all the advantages that you get with that.
Because Blazor has Bootstrap built in. You can replace that with
anything you want, of course, because it's just HTML and CSS. But Bootstrap is
built into the template, which makes it super responsive. So if
you have an iPad, it will be like everything is exploded. If you have a
small form factor device, a little Android phone, everything
will be collapsed and will be nice and responsive. And if you hold it
sideways, it will all go automatically with the user following their journey,
which is really, really great. You get all that stuff for free
because it's proven web technology that has been out there for a while, but you can
still get the performance. It runs as a native net application on that
device. You can reach into all the sensors,
you can use Geolocation, you can use the camera. Because if
you're running Blazor in a browser, then naturally you're going to be
bound to the browser sandbox, which is a good thing, right? You
don't want to go ending up to going to the wrong website and then
that website will format your hard drive. That's not something that we
can do or all kinds of other funny stuff. The good thing is that with Blazor
Hybrid, with .NET MAUI, you totally can format your hard drive
so that's there, right? You can run that application on
those devices. You're not bound to the sandbox anymore. Mind
you, for apps, there are still other sandboxes. You need all kinds of
permissions for that. So make sure that you request the right one. You still have
to know a little bit about cross platform development. Absolutely. Especially if
you're going to work with mobile devices. But you can now run your Blazor
application natively on that platform and access all the
power without having to worry about web services and all that kind
of stuff. So you can have offline applications, you can leverage all the
sensors, all the crazy, powerful, cool stuff there, and you can distribute it
through the app store, use push notifications and all that goodness
that comes with the mobile and desktop ecosystems. Then, before I go
into the Blazor Mobile Bindings, which is a different thing entirely, I
want to talk about Blazor United, which is the hot new thing that's
coming in .NET 8. At the time of recording, .NET 8 has not been
released, but Blazor United is coming as part of that. As the name kind of implies.
Blazor United unites Blazor WebAssembly and Blazor Server.
So you will get the best of both worlds then. What does
that mean exactly? Well, by combining both Blazor WebAssembly and Blazor Server,
we're going to try and minimize the disadvantages of both of these
technologies and maximize the advantages of both. For instance, that means with
Blazor United, you can stream new content to the client as it
comes in. So no initial download for a complete client application, but
you can just stream new things as they come in and still have
client side processing. And about that processing, you have full control
now, or there is an automatic mode about where things are rendered. Is this
going to be rendered by WebAssembly on the client? Or is this going to be
rendered by the server? Or is there an auto mode? And the technology is going
to decide automatically what is the optimum way to render this and
then push it to the client. This flexibility is particularly
valuable if your projects needs that interactivity and snappiness of a
client side application. But the security and the robustness of a
server side application, you have full control over what is rendered. Where
and how to exactly do that, it might sound a little bit cryptical
like this. Probably if you're going to look into the different Blazor things,
you might want to have a play with all of this and it will become clear
automatically. Or of course, if you want to know more about one of these
variations, let me know down in the comments. Now with all the flavors that I just
mentioned. Blazor WebAssembly, Blazor Server, Blazor United, Blazor Hybrid.
You can all share code between these projects as well. So if you have a
client side application with Blazor hybrid and you have architected your
application in a way that it used all kinds of reusable components because there
is no web target with .NET MAUI. So you can target
desktop and mobile devices, but not web, but you can wrap
everything in reusable components, you can reuse those components without
any change on the web in the browser by using Blazor United
or Blazor WebAssembly, which is super cool. And that makes
this solution super powerful. And what I didn't even mention yet
about the Blazor Hybrid approach is that it's also available for Windows Forms and
WPF. The Blazor Hybrid technology is built
upon a web view that's called the BlazorWebView, which is a specialized web
view for hosting Blazor applications. That BlazorWebView is built on top of
.NET 6 and also made available for WinForms and WPF. So as
long as your WinForms or WPF application can
get up to .NET 6 or, of course, .NET 7
or .NET 8, but least .NET 6, you can implement
that BlazorWebView inside of your application and kind of like
modernize. Your old gray Windows forms application from the
inside out by adding Blazor components that you already are
developing for your new web application or your new Blazor Hybrid application. So
the sky is the limit with this, basically.
Now then there is one odd one out, which is the Blazor Mobile Bindings,
which started as an experiment from Microsoft, also coming from the Blazor
Hybrid from the .NET MAUI side of things. But now it's more of a
community initiative that has taken the experiment from Microsoft and
taken it even further, which is basically bringing the Blazor the Razor syntax
to the .NET MAUI world. If you're going to build a .NET MAUI
app, which is a cross platform app built on C# and .NET, which runs across
iOS, Android, Windows, macOS, all those platforms
from a single code base, then you typically build your user
interface with XAML, which has been around forever since
WPF and... Do I dare say it? Silverlight! Or just plain C#
code. But with the Blazor syntax, a
lot of people have come to love that, which is basically mixing your
syntax just in line with C# code outputting, HTML and all
that kind of stuff. And that is exactly what the Blazor
Mobile Bindings do. It brings that Razor syntax into your .NET MAUI application,
basically replacing the XAML with Razor syntax. But in
this case, you're not mixing it with HTML and CSS, you're
mixing it with XAML components. So still the markup
components, but it has this more fluent way of mixing your logic with your UI
that a lot of people have come to love now that Blazor is back
around. So, if you're building .NET MAUI apps, the paradigm of .NET
MAUI is to translate everything on the abstraction layer. So a button,
a label to whatever that should be on the platform, right? A UI =Button
or a UILabel in case of iOS. And in this case with the
Blazor Mobile Bindings, we're not going to translate our UI to
a web UI. Some people don't like that, and I totally get why that is,
especially if you're building a mobile app. But in this case, the Blazor Mobile
Bindings are going to actually translate it to those platform components, just as
.NET MAUI is doing that, but with a completely different syntax
that people might find easier to write, or might find easier to read or
just easier to use and have more fun in life in general. And that is
all there is to know about the different Blazor flavors. I hope this
brings some clarity in your search for the right Blazor for you. Or did I miss
one or two? Let me know down in the comments so I can
learn from you. And of course this is all true for the time of recording
because Blazor and C# and .NET are developing at the speed of light.
So by the time you're watching this, some things might already be outdated
or there might be new stuff announced, which is really cool to work with. And
of course I will be there with a follow up video, so make sure to
subscribe to this channel so you don't miss anything. If you've liked this
one, please consider liking this video and I'll be seeing you for the next one.