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.
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
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.
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.
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.
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.
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.
Comparing 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.
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.
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.
If you want to find out more about Blazor and how to get started, I suggest you check out the following resources:
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. Follow her on Twitter or LinkedIn.
Subscribe to be the first to get our expert-written articles and tutorials for developers!