Blazor is a framework for building interactive client-side web user interfaces with .NET.
Currently there are a few hosting models:
All of these models are in different stages of development. The only finished product for now is Blazor Server, but WebAssembly is not far behind with its preview stage.
This article touches on the WebAssembly hosting model. This model makes development much easier with its use of CSS, HTML, and C# without any need for JavaScript. It can adapt to user needs of being tied to a specific app hosting model. User interface events are triggered and executed directly in the browser. In order to create new applications with this framework in the WebAssembly version, you need to have Visual Studio Preview 2019 with the latest ASP.NET and web development workload.Â
Creating a new Blazor application generates a new project which includes several data pages such as Home, Counter and Fetch. These pages are simple examples of the application’s capabilities. Interacting with the default application feels very snappy and without much load time on UI interaction. Other frameworks like MVC require client-side code execution with JavaScript, but Blazor can handle the application’s client-side code execution using C#.
On the outside, the rendered applications look similar to applications created in any other framework, but the code structure and the solution dictionaries are very different. By default, Blazor applications have files inside of the Pages folder that resemble View and Controller files from MVC applications, but they are merged together and have a .razor extension because they use Razor syntax.
The shared folder contains MainLayout.razor, which is the application’s master page, NavMenu.razor, which is the navigation bar code that was put in a separate file for simplicity purposes, as well as SurveyPrompt.razor. This improves code readability and allows for easier navigation between code. The NavMenu file is inserted in MainLayout as a custom tag helper that is replaced with code from the file in render.
Apart from the folders mentioned before, the solution’s root directory contains files like _Imports, App, and Program._Imports.razor contains namespaces that are used by the application. App.razor takes care of managing routing between pages and displaying errors if the client’s wanted page does not exist, just as it is illustrated in the example below. This file also contains DefaultLayout and Layout attributes that handle the usage of the selected layout in cases where the page does and does not exist. Program.cs is where the application takes care that it is correctly running.
A good example that represents new code structure on the default application is the Counter.razor page.
Application routing is managed with a @page code block which matches the URL path that accesses the page in that file (just use a slash for index). In the example below, we can see that variables used in a @code block can be used in HTML using Razor syntax. The way this code is merged in one file improves its readability and there is no need for file switching. The button for the on-click event IncrementCount is placed in the same block, too. This method increases the client-side currentCount variable by 1, just like we would do in other frameworks with JavaScript. This is a very simple code but it shows possibilities of client-side interaction with the user interface without using JavaScript enabled by running code in your browser.
ASP.NET Core SignalR is an open-source library that simplifies adding real-time web functionality to apps. Real-time web functionality enables server-side code to push content to clients instantly. This library is supported by Preview of Blazor WebAssembly version 3.2.0 and up.
This feature is one of the most interesting ones because it allows you to add real-time functionality to your Blazor application. This can be implemented in a variety of applications that contain notifications, frequent data updates or sending messages functionality.
The client connects to a hub which can be provided by your server; this handles the dispatching of messages to the clients. Communication between the client and the hub can be either JSON or a binary format based on MessagePack which will produce smaller messages.
An example for creating an application with implemented SignalR library like in the picture below can be found here.
A regular ASP. NET Core MVC renders the user interface as blocks of strings. Blazor 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 this representation. Any changes made to it will trigger a UI update for the affected DOM elements. This is a big difference in comparison to ASP. NET Core HTML Helpers and Razor Views, which render out strings.
This framework looks promising in regard to revolutionizing the development process of web applications. Blazor WebAssembly is still in preview mode until May when it will be released as a finished product. There is still time for exploring all the functionalities of Blazor and SignalR until the finished product with new features and presumably better performance is here.