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.
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.
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.
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.