Microsoft introduced .NET Core to create apps for any Operating system, be it Windows, Linux, iOS, Android or macOS. One thing all of ASP.NETs web solutions have in common is that they are server based. Now Microsoft introduced revolutionary client-side framework called Blazor with built on web standards, this allows us to write rich, engaging user interfaces using the power of C# and .NET.
Here in this post, we’ll cover the hosting models, introduction of components and the benefits of using them to build beautiful and engaging UIs all using C# and .NET, before we talk about different flavors of Blazor, let’s have a quick overview of components.
What are Blazor Components?
Blazor components are reusable parts of the application containing of user interface (UI) that are composed of HTML, CSS, C# code using Razor markup. These components can be part of whole page , a section of a page , form or a dialog box. Components are very flexible, lightweight, and easy to reuse, nest like parent and child, or even share across different applications, such as Razor Pages or MVC apps.
Blazor uses an abstraction layer called RenterTree between the DOM and the application code. Any changes that happen in a component, such as a button click that affects the state change of an app, Blazor render a graph and UI diff is calculated. click here to learn more about blazor-rendertree-explained . This diff (diffing algorithm maintains DOM tree) contains a set of DOM edits that are required to update the UI and is applied by the browser, we will see the diff in detail when we discuss about the hosting models. here are the few examples if a user interface structured as components.
Example: Layout divided into components
Example: Nesting components to form a component tree.
Anatomy of a Blazor component: Let’s look at an example of a component in Blazor standard project template. Couter.razor.
Understand hosting models: When you start working with Blazor, you come across the concept of hosting models. Hosting models are where the Blazor application is run.
Blazor comes with two main hosting models:
- Blazor Server
- Blazor WebAssembly (WASM)
whatever the model you choose, the underlying component model is the same for both models, Blazor has separation between hosting models and its application components, check this below image.
Blazor Server: Blazor server, often referred to as server-side Blazor, is a type of Blazor application that runs on a server. See below figure how the blazor server works.
Blazore server is an ASP.NET Core web application that initially receives the request. If the App is already running, a new session (SignalR connection) is established or if the request is first time, the app is started and a new session is established and payload is returned and files are processed and DOM is created. A file called blazor.server.js is executed, the job of this runtime is to establish a SignalR connection back to Blazor app running on the server.
Now user click a button in the browser. The action is dispatched to the server using runtime on the client [blazor.server.js], the server process the action and return the HTML diff to the browser and updates the UI using the diff.
NOTE: To make the diff, the server keeps a graph of the application state. It constructs the graph using components, which translates into Document Object Model (DOM) nodes.
- Tiny payload size
- Less abstraction
- Fast load time
- Access to the full runtime
- Code security
- Connection required
Blazor WebAssembly (WASM): Before getting into Blazor WebAssembly, let’s look at WebAssembly itself. WebAssembly (wasm) allows browser to run code ,such as C# and C++. Wasm is an open standard, and it runs in a sandboxed environment close to native speed on the client machine, enforcing browser security policies. Wasm binaries can interact with JavaScript.
Blazor WebAssembly is all about running .NET in the browser or run your app entirely inside the client’s browser making it a direct alternative to SPA frameworks. To understand how this hosting model works, let’s walk through the process of initializing a Blazor WebAssembly application.
Ok, let’s explain a bit more detail about the client side part of blazor. The process begins when a request is made by the browser to the webserver. As you see from the above figure, web sever will return a set of files need to load an application, these include the host page for the application, called Index.html, any static assets like images, CSS and JavaScript and a special JavaScript called blazor.webassembly.js.
Currently WebAssembly has a limitation, it can’t alter or call Web APIs directory, so Blazor framework resides in blazor.webassembly.js to manage client interaction, it does 3 things.
- Loads and initializes the Blazor application in the browser.
- Provide direct DOM manipulation so Blazor can perform UI updates.
- Provide APIs for JavaScript interop scenarios.
The files returned from the server are all static files, this means they can be hosted on any service which offers static hosting, no requirement for a .NET runtime to be present on the server.
Once the browser has received all the initial files it can process them and construct the Document Object Model (DOM). blazor.webassembly.js is executed, this performs many actions but in this context of starting the Blazor WebAssembly app, it download a file called blazor.boot.json, this file contains an inventory of all of the framework and application files which are required to run the app. along with these files, another type of file which is downloaded called dotnet.wasm.
The dotnet.wasm file is in fact a complete .NET runtime, which has been compiled to WebAssembly. Once the blazor.boot.json file has been downloaded and the files listed in it have been downloaded, it’s time for the application to be run. The WebAssembly .NET runtime is initialized which in turn loads the Blazor framework and finally the application itself. At this point we have a running Blazor application which exists entirely inside the client’s browser.
Calculte UI Updates: How to UI updated get calculated, see the below figure.
- User clicks the “Counter” link to go to the Counter page.
- The navigation event is intercepted by Blazor on the JavaScript side
- This event is passed to Blazor on the WebAssembly side and processed by Blazor router component. if it finds the Counter component, a new instance of that component will be created and the relevant lifecycle methods will be executed. Once complete Blazor work out the minimum amount of changes that are required to update the DOM.
- The changes will be passed back down to the Blazor JavaScript runtime .
- Changes are applied to the physical DOM. At this point the UI will be updated.
All of this has happened client-side in the user browser. there was no need for a server during any point in this process.
Benifits:
- Application run on the client.
- Can work in offline scenario, enable Progressive Web Application(PWA) functionality.
- Deployed as static files.
- Code sharing
Tradeoffs:
- Payload, the initial download size for a Blazor WebAssembly app can be considered quite large.
- Load time, If the user’s on a poor internet connection the amount of time required to download the initial files will be higher, which will delay the start of the application, leaving the user with a loading message of some kind.
- Restricted Runtime
This completed the introduction to Blazor, let me know your comments. thank you very much.