adopting-blazor_1200x303

Curious about adopting Blazor and how it works? Wondering whether client-side or server-side hosting is the best fit for you? Catch our webinar recap to learn what you need to know.

We covered a lot of ground in our Telerik UI for Blazor webinar and wanted to share a recap of the event. If you missed the live webinar or want to watch it again or share it with a friend or colleague, you can find the recording HERE.

In this post you’ll learn all about the Blazor framework and architecture, and how we feel Blazor is going to change the ASP.NET development ecosystem.

What is Blazor?

To begin, Blazor is a brand-new framework from Microsoft that aims to allow developers to build SPA applications using existing .NET technologies. And the Blazor framework has features that you would see in popular frameworks like Angular or React, but all of this is being done with .NET. We have features like server-side rendering, forms and validation, routing, client-side routing, unit testing, and especially important for us here on the Telerik team, component packages—all right out of the box.

Telerik UI for Blazor Components Telerik UI for Blazor Components

Let's take a look at the architecture of Blazor and learn a little bit more about how we're able to write full stack .NET applications that run on the client. Blazor itself is independent of the way the application is hosted. And there's actually two ways of hosting a Blazor application right now. We have a client-side hosting model and a server-side hosting model. And I'm going to dive into exactly what each of these are and how they're implemented.

It's important to note that the client-side version of Blazor runs on WebAssembly, which will be released with .NET 5 in May of 2020. In the meantime, the server-side rendering portion of Blazor is fully supported now that .NET Core 3 has launched.

Client-Side Hosting Model

First of all, let's learn how the client-side version of Blazor works. In a typical browser, we have the browser engine that takes in JavaScript, and it sends it through a parser. That JavaScript then gets compiled and turned into byte code. And once we have our application loaded in the browser, it can interact with the DOM and run APIs.

 

Blazor Client-Side Hosting Model WebAssembly - Client-Side Blazor 

There's a new technology available to us called WebAssembly. WebAssembly is a byte code that browsers can execute and what makes WebAssembly different is that it's parsed and compiled before it's delivered to the browser. Languages other than JavaScript, such as C++ and C#, can be compiled directly to byte code and used by the browser. So, this is what Microsoft has done—they've taken the .NET runtime and compile to WebAssembly to run .NET into the browser.

WebAssembly and the .NET runtime running in the browser is what enables Blazor to run client-side. When Blazor is running in the client, this enables us to use .NET assemblies and run our .NET application code within the browser without any plugins, because it's using all web standard technologies. Essentially, Blazor applications are .NET applications that run on the client.

Server-Side Hosting Model

Now, let’s take a look at the server-side version of Blazor and how its implemented on the server. Unlike the client-side version of Blazor, server-side Blazor runs without WebAssembly. All of your code for your application is hosted on the server and it runs in your server and connects to the client and uses it as a thin client.

Blazor Server-Side Hosting ModelBlazor Server-Side Hosting Model

There's a small JavaScript payload that's sent to your browser. It connects through SignalR and sends information to your application through WebSockets. Once you have that connection established, your browser then can send events and updates to the application running on the server. Blazor then figures out what elements need to change on your screen, and sends only those changes down to the browser to make those changes in the DOM.

One thing that's nice about the client-side architecture is it can be a very vertical slice architecture. There's not a lot of overhead because you have your application running where the data may be stored, enabling you to write applications extremely quickly. There's not a need for an N-tier application in some scenarios.

A Side-by-Side Comparison

If we look at that two side-by-side, we have some benefits of each hosting model. With client-side Blazor, we have little to no server overhead because everything is running on the .NET framework within the client in their browser. It's a RESTful technology just like Angular, React, or an Ajax application. And it's capable of doing offline and PWA type of work as well.

Blazor Hosting Models ComparisonComparing Blazor Hosting Models

Some of the downsides to running on the client include the larger payload size, because we're shipping code to the client. And just as much as RESTful can be a positive it's a disconnected environment, and that's something that we have to be aware of. Support for client-side Blazor is tracking for May of 2020.

Looking at the server-side of things, we have a very small payload size. We're only sending over a JavaScript file and small binary packages that contain updates for the browser. There's potentially less abstraction, because it's a connected environment. It has pre-rendering supported out of the box, great for SEO and it’s supported today. And with Microsoft launching support for ASP.NET Core 3.0, everything you need for server-side Blazor comes with that.

When it comes to server-side, some of the potential downsides are that a constant connection is required for your application to operate because of the WebSocket technology, and you're expending server resources versus sending everything to the client to be processed.

Hopefully that served as a good top-level overview of how the two hosting models square up.

Now, it's important to note that while we're thinking that there's two hosting models here, the code that you write for both is going to be about 99% identical. The only things that change between a client and server app is how you access your data. All the components that you write, and all your UI logic will be 100% identical between these two models.

Blazor Prerequisites

As far as prerequisites for Blazor, you'll need the .NET Core SDK. And in the future for Blazor on the client-side, you may need updated preview bits for the .NET SDK. Same thing goes for Visual Studio, you'll need Visual Studio 2019. For folks that want to use the client-side version of this technology, you should stay on the preview channel of Visual Studio because it gets constant updates from the ASP.NET team. For server-side Blazor, you should be good with .NET Core 3.0 in Visual Studio 2019.

Finally, when it comes to our Telerik UI for Blazor components, what we're finding is that we don't have any special use cases when we're using either client or server technology—they work in both instances.

Learn More About Blazor

If you want to find out more about Blazor and how to get started, I suggest you check out the following resources:

 


Maria Veledinova
About the Author

Maria Veledinova

Maria Veledinova is Product Manager for Telerik UI .NET Web components - Blazor, ASP.NET Core, MVC and AJAX. She has experience in the field of product development and transformations of organizations towards forward-looking, innovative and impactful software products. Maria believes that behind every great product along with the cutting-edge technology stands challenging the status quo, close collaboration with the customers, and spirit of experimentation.

Related Posts

Comments

Comments are disabled in preview mode.