A year back, Microsoft had released the Blazor, which was a new experimental .NET web framework which combines the power of C#/Razor and HTML that runs in the browser with WebAssembly.
What is Blazor?
Blazor is basically a single-page app framework where developers can build interactive client-side Web apps with .NET. It uses open web standards sans the plugins or code transpilation. Blazor functions well in all modern web browsers, including the mobile browsers.
As a developer, you program the code in C# in the case of JavaScript, and you use most of the .NET ecosystem of open source libraries. For the majority of the part, if it is a .NET Standard, it will function in the browser.
The code of .NET runs inside the context of WebAssembly. In this case, what you are doing is, running a a ‘.NET’ inside your browser on the client-side with no use of plugins, no Silverlight, Java, Flash, but just the open web standards.
Key benefits of using Blazor
- Blazor runs in a memory safe sandboxed environment and is as fast as native applications.
- Required SPA features are easily supported by Blazor like components, routing, dependency injection for an up to date experience as a programmer.
- You can deploy Blazor applications on machines having no .NET, just as static files.
- Blazor comes with ultra-rich IntelliSense and tooling for lesser development time.
- It is supported by all mainstream browsers like Chrome, Edge, Firefox, Opera, Safari along with the ability to run on older (non-WebAssembly) ones via asm.js.
Let’s understand the difference between Blazor and BotS. From “the code on the ground” point of view, there is no major difference . Just by looking at the code, it is clearly impossible to tell whether you’re working with Blazor-on-the-Client or Blazor-on-the-Server. A major differentiating factor between the two is- where your C# code executes — is hidden from you.
In case of BotS, SignalR automatically connects activities in the browser with your C# code executing on the server. That support of SignalR makes Blazor solutions much less scalable than other Web technologies since SignalR has to maintain WebSocket connections between the client and the server. However, that scalability issue may not be as much of a limitation as you might think.
BotS “normalizes” a majority of the ad hoc ways that have been needed when working Blazor in previous releases. The components of BotS are just another part of an ASP.NET Core project and play well beside other ASP.NET Core technologies like Razor Pages, View Components and good old Controllers+Views.
Visual Studio also has templates which allow you to create a single project supporting BotS without having to generate additional “support projects.” Pages enabled with Blazor also now have their own file extension (.razor) and their own spot in an ASP.NET Core project’s structure. They reside in a folder called Components.
Giving you the opportunity to substantially reduce the size of your toolkit by leveraging C# code for client-side activities. You won’t be able to completely give up JavaScript though. You’ll still need some JavaScript code, for example, when you need to access the various HTML5 APIs (though packages like Blazor.Geolocation may render that unnecessary, also). At that point, you’ll take advantage of Blazor’s ability to integrate C# code with JavaScript.
How blazor compares to ASP.NET Core MVC applications
A normal ASP. NET Core MVC renders the UI as blocks of strings as we know it. Blazor, on the other hand, builds a render tree, which is not a string, but a representation of the DOM (Document Object Model) that is held in memory. Blazor keeps that representation.
Any changes made to it (for instance, when a binding value is updated) will trigger a UI update for the affected DOM elements. This one major difference, compared to ASP. NET Core HTML Helpers and Razor Views, it render out strings.
So why does Blazor work with render trees instead of strings? Remember that Blazor code in particular (and wasm code in general) cannot access DOM elements directly. This limitation is different from ASP. NET Core HTML Helpers and Razor Views, they depend on JavaScript for full access to the UI elements.
In this case, Blazor relies on rendering trees to go back to its DOM representation, looks for specific pieces of the DOM, updates them, edit, delete, and so on and so forth. Blazor framework listens to changes made to the data model and manipulates the render tree thereby applying the changes. This mechanism is what allows C# to work on the client-side.
Conclusion
Why should an ASP.NET application development company choose to develop with Blazor rather than pure client-side JavaScript or ASP. NET Core MVC/Razor? Maybe now we have our answer. Blazor provides all the benefits that a company needs in order to sustain a powerful web application. And on the other side, it has all the required features to help developers build applications with ease and power.
Originally published at https://www.hiddenbrains.com on February 24, 2020.
