Terug naar overzicht

Lets talk Blazor.NET

Hi there, my name is David Vanderheyden. A dad of 3 awesome kids, husband, and a .NET enthusiast at Noest. In my Everlong quest to keep updated with new technologies, I found myself convincing colleagues of why I think Blazor should be on everyone's radar. And I thought, why not share this and potentially convince a broader audience? So I wrote this blogpost to quickly share the what, how, and why. And hopefully, I can trigger the interest within you for Blazor.

David Vanderheyden

The good and the bad of 2020

2020 has been a tough year for a lot of us so far, due to the Covid-19 virus. But it's shaping up to be a great year for technological improvements. And the year is not over yet, in November the expected official release of .NET 5 is something to follow up on. Microsoft has been making a lot of changes to the .NET Framework in an attempt to shift towards unifying .NET 5 framework (Figure 1). This framework is meant to run anywhere and build applications, ranging from desktop applications to the web, cloud, gaming, mobile, IoT, or even AI applications in a uniform manner.

Mt833477 0719 michaelis figure2 hiresen usmsdn 10

Figure 1 .NET 5 - a Unified Platform (source)

The evolution of .NET Core

In June 2016 Microsoft released the first major version of .NET Core (Figure 2), the first cross-platform successor to the .NET Framework, that was focused on high-performance web and microservices.

With the release of the second major version, APIs and components were added to facilitate migrations of web applications to .NET Core. This was also the first step Microsoft made in shifting towards a unifying platform.

With the release of .NET Core 3.0 in September 2019, Microsoft announced support for ARM64, improved performances, adding JSON APIs, Windows Forms, and WPF to the framework. Only 3 months later, Microsoft released .NET Core 3.1 with only two big additions, key improvements to Blazor and Windows Desktop.

Dotnet timeline 1

Figure 2. Source Code Flow Concept from .NET, Mono and Shared Source Initiative to .NET 5 (source)

Wait, improvements on Blazor?

Yes, Blazor has been around for a little over two and a half years. It started as an experimental project led by Steve Sanderson (Knockout.js), with the goal of building a client web UI framework based on .NET and WebAssembly. Since then Microsoft has shipped nine experimental Blazor releases until April 2019, when an official preview was released. Blazor server was officially released shortly after with the release of .NET Core 3. For Blazor WebAssembly we had to wait until May this year where it was officially released at Microsoft Build 2020.

What is Blazor?

Blazor is a .NET based Single Page Application framework (hereafter SPA). This means that a single web page is dynamically rewritten by the interaction on that page instead of the browser loading entire new pages in a classic web application. A SPA makes a web application feel like a native app. Popular and commonly used SPAs are JavaScript frameworks like Angular, Ember, React, and Vue. These JavaScript frameworks run on the client, which means that the application is run from within your browser. However, instead of using JavaScript, Blazor uses C# for processing instead. Making it possible for developers to share code across client and server. Blazor declares HTML with Razor script, known from MVC and Razor Pages.

It's also possible to create and use reusable Blazor components written in C#. On top of that, it's possible to call third-party JavaScript frameworks and libraries using a JavaScript interop. Using the JavaScript interop you can call JavaScript code and JavaScript code can call into C# code.

Blazor currently has 2 ways of hosting, Blazor Server and Blazor WebAssembly. Both follow the SPA framework rules, but both work in completely different ways.

Blazor Server

Blazor server (Figure 3) runs as the name implies, on the server, and not in the client's browser. Your browser loads an entirely new page at the start. After that, all the interactions are sent to the server using SignalR. The server pre-renders the HTML content that changes and sends that content again using SignalR to the client's browser so it can dynamically rewrite the page. Blazor server makes your browser some sort of terminal. This way of working has advantages and disadvantages, which should be considered carefully when choosing Blazor Server.

The pros

  • Search engine friendly
  • No start-up time
  • Works on older browsers
  • Easier to debug
  • Same code on the client as on the server

The cons

  • Uses in-memory session for each client
  • Clients are bound to the server containing the session, so load-balancing doesn't work
  • The round trip (the interaction on the page is being sent to the server, server pre-renders the HTML, sends the HTML back as a package to the client, the client browser processes and displays page with changes) can feel slow and inactive when the server and the client's browser are not close or have a slow network connection between them.
  • large input content results in large network transfer
  • The application is unresponsive when the connection with the server is lost until Blazor re-establishes the connection to the server.
Blazor server

Figure 3 Blazor Server (source)

Blazor WebAssembly

Blazor WebAssembly runs completely on the client's browser. Note that this is not like previous attempts from Microsoft with Silverlight to host an in-browser application that required browser plugins. It uses web standard WebAssembly. WebAssembly allows the compilation of code for the web browser. A Blazor WebAssembly is therefore completely run by using WebAssembly within the browser. When launching the web application for the first time, it will load the application. After loading, it will run the application inside your browser. There are also things to be considered carefully when choosing Blazor WebAssembly

The pros

  • Runs completely on the client's browser which means the server load is significantly reduced.
  • Works off-line (obviously, it won't be able to talk to the server to sync data until it re-establishes a connection)
  • Will not run directly from the local file system
  • Capable of being run as a Progressive Web App
  • Same code on the client as on the server

The cons

  • It downloads all required .NET assemblies, so start-up time is slower than server-side
  • Blazor WebAssembly does not yet support multithreading
  • Only works on newer browsers, which mean it doesn't work with most thin clients
Blazor webassembly

Figure 4 Blazor WebAssembly Source

What the future holds for Blazor

What the exact roadmap contains to date is unclear, since this is the last roadmap shown and dates from September last year.

There are a few Hybrid experiments ongoing that are worth following.

One of those is Blazor+Electron. Using Electron makes it possible to build desktop applications with the ease of HTML, but run them on any OS. Electron works by running Chromium, for the frontend code, and Node.js for the back-end code with WebAssembly. But this comes with a cost, it adds overhead to the system. A simple application easily becomes +50MB in size, and when launched it eats up +100MB memory.

Another experiment by Microsoft (Steve Sanderson) is named WebWindow. Same as Electron, WebWindow makes it possible to build desktop applications that run on any OS. But unlike Electron it doesn’t bundle Node.js or Chromium, making it more lightweight. WebWindow is just a prototype, so by far not production-ready. But this would be a game-changer for desktop application development.

Yet another experiment is mobile Blazor bindings, this should enable native mobile application development with Blazor. Thus making it possible to build mobile applications with the ease of HTML using Razor syntax.

June 2020 gRPC-Web for .NET officially released and makes it possible to connect a Blazor app with one or many gRPC services.

Huge improvements expected later this year on Blazor are component model improvements, hot reloading, and CSS isolation. WebAssembly-specific improvements expected later this year are multithreaded runtime and lazy loading.

We can make an overall conclusion that is clear: Microsoft has many plans with Blazor and sees it as a long-term competitor to JavaScript frameworks like Angular, React, and Vue and even projects like Flutter and React Native. It’s not only trying to displace JavaScript, but offers the possibility to bring web development, desktop development, and native development closer together. Even more, Blazor is part of the open-source .NET platform and has a strong active community of over 60.000 contributors that answer questions, producing samples, writing reusable UI components, and more.

Blazor spectrum2

Figure 5 (Source)

Summary

I’m over-excited about the status of Blazor today and things to come. Today it already has so many benefits, we can’t look beside it. A lot of developers who worked with Blazor say: “Blazor server is Webforms done right”. On top of that being able to make a complete client-side SPA with Blazor WebAssembly opens so many new opportunities. But most of all, the reusability of code and components benefits the development speed in the long run. Also making it possible to have everything inside the same stack and not distributed in multiple languages and/or frameworks, is a blessing for developers.

It's tough to find developers that are good at both JavaScript and C#. With Blazor as the technology of choice, back-end C# developers automatically have knowledge of front-end development with Blazor. Making it easier for back-end developers to shift between fixing bugs on the front-end or skill-up on building front-end applications.

If your business needs a production-ready SPA right now and there is expertise in a JavaScript SPA framework then that would be a better choice than Blazor to date. But if there is no JavaScript knowledge and the steep learning curve for JavaScript is at stake. Then consider Blazor. When the hybrid experiments and further development on Blazor’s roadmap succeeds, then I’m convinced that Blazor will become the only path to take, but let’s keep a close eye on the progress for that decision and re-evaluate in the hopefully near future.

Thanks for reading and stay safe.

Deze website maakt gebruik van cookies om ervoor te zorgen dat u de beste surfervaring op onze website krijgt. Meer info