Blazor is now heading for the big time, to be packaged with the next release of .NET Core, ready for the production use. Specifically, some elements of Microsoft’s experimental Blazor project for running .NET code in the browser will be included in .NET Core 3.0, Microsoft said yesterday.
.NET Core 3
The highlight .NET Core 3 is for Windows desktop applications, specifically Windows Forms, Windows Presentation Framework (WPF), and UWP XAML. You can run the new and existing Windows desktop applications on .NET Core and enjoy all the benefits that .NET Core has to offer.
Importance of .NET core 3
There are lots of benefits of .NET core 3 that are that are great for desktop apps. There are a few points that are worth calling out:
- .NET core 3 can access the full Windows 10 (AKA “WinRT”).
- .NET core 3 ability to host UWP XAML controls in WPF and Windows Forms applications.
- .NET core 3 Ability to host UWP browser and media controls, enabling modern browser and media content and standards.
The Blazor elements model to be included in ASP .NET Core and shipped with .NET Core 3.0 was given the new name “Razor Components” to differentiate it from the ability to run .NET, Roth said.” Now we are working towards shipping Razor Components and the editing in .NET Core 3.0” Roth said. “This includes integrating Razor Elements into ASP .NET Core so that it can be used from MVC. We have a preview of this support early next year after the ASP .NET Core 2.2 releases have wrapped up.
“Our main goal remains to ship support for running Blazor client-side in the browser. Work on running Blazor client-side on Web Assembly will continue in parallel with the Razor Components work, although it will remain experimental for a while longer while we work through the issues of running .NET on Web Assembly. We will, however, keep the component model the same anyhow of whether you are running on the server or the client. You can shift your Blazor app to run on the client or the server by changing a single line of code.”
The news about Razor Components was in a blog post announcing the latest update to the project, Blazor 0.6.0.
One important new feature of the update is the addition of templated components. “Templated components are components that help you to accept one or more UI templates as parameters, which can then be used as part of the component’s rendering logic,” Roth explained. “Templated components also allow you to author higher-level components which are more reusable than what was possible before. For example, a list view component could allow them to specify a template for rending items in the list, or a grid component could allow the user to specify templates for the grid header and for every row.”
Another new feature is refactored server-side Blazor code to support the Azure SignalR Service. “In the last Blazor release we added support for running Blazor on the server where UI interactions and DOM updates are handled over a SignalR connection,” Roth said. “In this new version, we refactored the server-side Blazor support to enable using server-side Blazor with the Azure SignalR Service. The Azure SignalR Service controls connection scale out for SignalR based apps, scaling up to handle thousands of persistent connections so that you don’t have to.”
Benefits of Server-Side Model
We have touched on some of the benefits already, but let me go through them all properly.
.NET Core APIs
The application is running server-side user have access to all of the .NET Core APIs files. If the user were looking to convert an MVC application, for example, you should be able to access everything you do in the MVC app in Blazor.
As I’ve mentioned before, you will get that SPA to feel with your server-side app. There will no unnecessary page refresh and the app will have a very rich interactive feel.
Much Small Downloads
In comparison to the client-side version Server-side Blazor (Razor Components) has a much smaller download. This leads to significantly faster startup times for your application.
Carrying on from the before the benefit, smaller download and the fact server-side doesn’t require Web Assembly means your app can be consumed by a wider range of clients. As the main processing is done server-side lower powered devices will target as well.
The present development experience with client-side is still very much a work in progress. While it’s improving every launch, the user still can’t hit F5 in Visual Studio and get the normal debugging experience we all are used to. That is not the case with server-side apps, user gets access to all the great asp.net developers tools you’re used to.