Benefits of Blazor for .NET Applications

June 08, 2020 / Bryan Reynolds

Reading Time: 10 minutes

.NET developers have been waiting a long time for a complete Blazor framework that’s ready for production. This solution would allow a .NET developer to build web applications with C#, which provides performance and implementation advantages over JavaScript. Microsoft announced in May 2020 at the Build developer conference that Blazor WebAssembly 3.2 will be joining Blazor Server, which runs on the server side by using .NET Core.

The new apps allow a .NET developer to use Blazor for both client and server-side apps. Blazor handles interactions and updates to the user interface (UI) with a real-time WebSocket connection to the browser. Blazor WebAssembly users can also expect client-side apps to receive similar improvements to load times and implementation that Blazor Server already provides for the server side.

.NET Core

.NET Core is an open-source software framework developed primarily by Microsoft and distributed under the MIT License. It’s a cross-platform successor to .NET Framework that works for major operating systems (OSs), including Linux, macOS and Windows.

The last major update to .NET Core will be version 3, which was released in 2019. This version adds support for the development of desktop apps, Internet of Things (IoT) apps, artificial intelligence (AI) and machine learning (ML). The current version of .NET Core is 3.1, after which Microsoft will deprecate the .NET Framework.

Microsoft will remove the “Core” branding from the product name to reflect the fact that it will be the only version of .NET going forward. Furthermore, version 4 will be skipped to avoid confusion with .NET Framework v4.x. The next version of .NET Core will therefore be .NET 5, which Microsoft originally previewed in March 2020.

.NET Core supports four cross-platform solutions, including ASP.NET Core web apps, Universal Windows Platform (UWP), command-line apps and libraries. It also implements Windows Presentation Foundation (WPF) and Windows Forms as of version 3, which render a graphic user interface (GUI) for Windows desktop software. In addition, .NET Core supports NuGet packages that include .NET Framework packages and packages written in C++. .NET Core receives updates through its package manager, whereas .NET Framework relies on Windows Update.

CoreCLR and CoreFX are the two primary components of .NET Core. CoreCLR is comparable to .NET Framework’s Common Language Runtime (CLR). It’s an implementation of Virtual Execution System (VES), which makes CoreCLR a complete runtime environment for managing the execution of .NET apps. It also includes a just-in-time (JIT) compiler called RyuJIT.

CoreFX is equivalent to the Common Language Infrastructure (CLI) in .NET Framework. It’s an implementation of .NET Framework’s Standard Libraries, so it shares a subset of .NET Framework APIs. CoreFX also includes APIs that aren’t part of .NET Framework.

The .NET Core command-line interface provides an entry point for operating systems and offers developer services such as compilation and package management. .NET Core also includes CoreRT, which is the .NET Native runtime environment optimized for ahead-of-time (AOT) compilation. Additionally, UWP uses a variant of the .NET Core library.


Blazor is a open-source framework under development by Microsoft that allows developers to create web apps with C# and HTML. Its two major components are Blazor Server and Blazor WebAssembly, which handle server-side and client-side apps respectively.

Blazor Server was initially released as part of .NET Core v3.0. An ASP.NET Core server hosts Blazor Server apps in Razor format. The user’s computer acts a thin client for these apps, meaning that the server handles most of the workload for Blazor Server. The client’s web browser only needs to download a small page that it uses to update its UI.

Blazor WebAssembly is a client-side framework written in WebAssembly instead of JavaScript, which is by far the most common language that developers use for web apps. Microsoft has released beta versions of Blazor WebAssembly as previews since February 2020, but it has only been generally available since May 2020. Blazor WebAssembly allows users to download single-page applications (SPAs) to their browser before running them. This download is larger than the ones that Blazor Server uses since the client performs all the processing for Blazor WebAssembly. This client-side processing also provides Blazor WebAssembly apps with faster response times.

Microsoft also plans to release Hybrid and PWA editions of Blazor in the near future. Hybrid Blazor is a platform-native framework instead of a web framework, although it still renders the UI with web technologies like CSS and HTML. PWA Blazor supports progressive web apps (PWA). Microsoft is also considering a native edition of Blazor that would be a platform-native framework that renders UIs on the user’s own platform. However, this project isn’t even in the planning stage yet.

Current Features

Blazor WebAssembly 3.2 Release Candidate is the first complete release of the client-side component of Blazor, which Microsoft released in April 2020. This release candidate is only one step away from the production version, which should debut shortly after Microsoft’s Build developer conference that began on May 19. The release candidate (RC) should be virtually identical to the upcoming production version, since Microsoft has already stated that it isn’t adding any new features or performance improvements for the production release of Blazor WebAssembly. The only changes to WebAssembly at this point should be bug fixes.

In fact, the latest RC only adds two features. The first is that developers can customize how their boot resources are loaded with a new API. These resources include bootstrapping JavaScript code, location-specific data, required .NET assemblies and the .NET runtime. The second new feature in the current RC is the API documentation for the namespace is now available in the API browser as of ASP.NET Core 3.1. These namespaces are documented in Microsoft.AspNetCore.Components.WebAssembly.*.

Existing Features

Blazor WebAssembly 3.2 also includes many existing features already introduced in previous releases. These include the ability to use strong runtime typing, which increases productivity when using C#. Developers can also reuse code and the existing .NET Standard libraries on both the client and server sides. Furthermore, they can share components between Blazor server apps. Additional benefits for developers include the ability to deploy apps as either a standalone site or one that hosts ASP.NET Core.

Developers who use Blazor WebAssembly can build Progressive Web Apps (PWA), which allows the app to be executed off-line and integrate with the native OS. Blazor also offers built-in support for user authentication and integrate support for globalization and localization functions. In addition, Blazor WebAssembly provides developers with technical capabilities like environment-based configuration, intermediate language (IL) trimming, build-time compression and full-stack debugging.

Developers can also leverage the stability and maturity of the .NET platform. For example, they can use tools from the Visual Studio (VS) suite, including Visual Studio, Visual Studio Code and Visual Studio for Mac.

The latest RC of Blazor WebAssembly requires version 3.1.201 or later of the .NET Core Software Development Kit (SDK). However, WebAssembly still has a blocking issue that Microsoft will need to fix before its general release. This problem prevents satellite assemblies from the client application from getting copied to the publish folder when the developer publishes an app hosted by ASP.NET Core using VS.

Single-page Apps

An SPA is a web app or website that dynamically rewrites a web page with new data from the web server. In contrast, the default method for an app to interact with a web browser is to load the entire page. The primary advantage of SPAs is that they have faster transitions, making the remote website behave more like a native app.

SPAs generally require the browser to retrieve all code with a single page load, including CSS, JavaScript and HTML. It must also dynamically load resources to the page, typically in response to an action from the user. The page never reloads at any point, nor does it transfer control over its data to another page. However, an SPA can use The HTML 5 History API or location hash to provide navigation and perception functions for the app’s separate logical pages.

Ajax is currently the most common SPA technique, which primarily uses the XMLHttpRequest/ActiveX Object object that has already been deprecated from JavaScript. Ajax also uses HTML and IFRAME script elements, along with objects and libraries like jQuery. These objects normalize Ajax’s behavior across different browsers, which is a major source of its popularity.

SPAs are part of the current trend away from the page-redraw model that browsers originally used. This model doesn’t track the webpage’s state, which is now creating some challenges for today’s web developers. Solutions to these problems include the evolution of browsers themselves and the HTML5 specification. Server-side web frameworks are using the SPA with growing frequency, and client-side script libraries are using various methods to address problems with the page-redraw model.

Use Cases

Blazor is designed to build SPAs with C# and .NET rather than the traditional choice of JavaScript. Blazor WebAssembly provides developers with a second way to host their Blazor components in addition to Blazor Server. WebAssembly is a .NET runtime that uses a standardized byte code for the web. Users download WebAssembly with their app, allowing them to run normal .NET code directly in their browser.

Blazor Server has been available since September 2019 as part of.NET Core 3.0, but Blazor WebAssembly wasn’t ready at that time due to problems with WebAssembly. The WebAssembly .NET runtime is improving quickly, but it still has limited debugging capability, considerable room for performance improvement, and overly large downloads. AOT isn’t an option for client-side apps like Blazor WebAssembly.

Microsoft has been promoting Blazor heavily because it allows Microsoft-centric coders to leverage their .NET skills in creating agile in-browser web apps with C# that also have back-end support from the server. This combination of capabilities means that developers can build client-side web apps that run entirely in the browser. They run faster and require less memory than apps written in JavaScript. Furthermore, running .NET on WebAssembly allows developers to reuse code and other components within .NET.

The Microsoft Build conference held in May, 2020 was an online-only event due to the COVID-19 pandemic. It covered an especially large amount of developer content this year, which included some Blazor presentations. These included “Learn Studio Session: Build a WebAssembly app with Blazor & VS Code” and “Modern Web UI with Blazor WebAssembly.” The Blazor renderer initially targeted the web, but these presentations show that Microsoft is considering additional use cases for Blazor apps, including mobile devices, desktops and PWAs.

The following diagram shows the spectrum of Blazor use cases, from web apps for Blazor Server to mobile and desktop apps for Blazor Native.

Blazer targets

Figure 1: Blazor Targets

Blazor Server

Blazor Server is most useful for pure web apps running entirely on the server. It also has the option of pre-rendering the UI with HTML.

Blazor WebAssembly

Microsoft is specifically targeting Blazor WebAssembly for general availability in May 2020, given that it wasn’t ready to be included in .NET Core 3.0. Observers also expect continuing previews of Blazor WebAssembly use cases leading up to the expected release of .NET 5 scheduled for November 2020. This version of .NET will consolidate the entire .NET ecosystem.

Blazor PWA

A PWA web app uses modern web standards to enable features like offline support. This capability requires developers to add a service that caches files so the browser can access them when it isn’t connected to the internet. PWAs also support push notifications due to their fast response times that give server-side apps a native feel.

Some platforms allow PWA apps to be installed into the OS. For example, users can install these apps on Windows 10 so they can run them from the Start menu. Phone users can also pin them to their home screen.

Blazor Hybrid

Blazor Hybrid apps are share features of native and web apps. They run natively on the user’s device and have access to all the capabilities on that device. However, they also use web technologies to render their UI. For example, hybrid apps include apps that run natively on a mobile device, but use a webview for the UI. Microsoft representatives reported at the recent Build conference that they have been conducting experiments in this area.

Blazor Native

Blazor Native apps are fully native, representing the bottom of the Blazor spectrum from web to native apps. They use native controls to render the UI instead of web technologies, which is faster and provides greater control over the UI. Microsoft has also been investigating this area of .NET software development with Blazor, which was originally designed for an extensible renderer. Blazor renders with HTML by default since it’s primarily used to build web applications. However, developers can replace this rendering method with another one if they prefer, which could include native controls.

This approach is similar to what developers can already do with other technologies like React Native and Xamarin. These applications run natively on the user’s device, but they can also render with native controls. This cross-platform capability is becoming increasingly important to .NET developers, who often work on projects for different platforms at the same time.

Microsoft is looking to do this with a native version of Blazor, although it doesn’t yet have anything to share on this issue as of the 2020 Build conference. However, Microsoft did detail a method for using Blazor to create installable apps for the desktop at its Focus on Blazor event in early 2020. This alternative to rendering doesn’t rely on the traditional techniques of PWA and Electron, both of which have disadvantages compared to a native approach. PWA is lightweight, although it doesn’t provide access to native code or the OS. Electron does offer this access, but at the expense of a large download that’s slow to run.

The new approach for Microsoft is called WebWindows, which allows developers to write native code while producing a download that’s small enough to run quickly. Furthermore, WebWindows isn’t subject to the limitation of browsers and doesn’t run on WebAssembly.

Platform Unification

The early release of a production-ready version of Blazor is the latest event in Microsoft’s ongoing effort to unify .NET under.NET 5, which should be available by November. .NET developers have long been waiting for an open-source, cross-platform alternative to .NET Framework, which only works on Windows and not showing its age.

The following diagram shows how .NET 5 unifies the .NET ecosystem:

Dot net platform

Figure 2: .NET 5

.NET 5 provides software for desktops through Windows Forms, WBF and UWP. Developers can build mobile apps with Xamarin and web apps with ASP.NET. .NET 5 also enables the development of apps for the cloud, gaming, IoT and AI. The .NET 5 infrastructure includes compilers, languages, and the components comprising the runtime environment. Developer tools for this version of .NET include the VS suite and a command line interface.


The roadmap for the various forms of Blazor is as follows:


Figure 3: Blazor Roadmap

Blazor Server and WebAssembly are already available, while PWA and Electron should be available by November 2020 with the release of .NET 5. Microsoft is shifting its attention to .NET 5 now that it has shipped WebAssembly and is already working on including WebAssembly in .NET 5. The availability date of Blazor Native is still unknown as of May 2020. The exact features and improvements for Blazor that will be included in .NET 5 are still under investigation, but they’re expected to be extensive. The Blazor Roadmap for .NET 5 provides the complete list of core deliverables that Microsoft is considering.

Some of the more notable improvements in .NET 5 should include the ability to build .NET from a single codebase, allowing developers to collaborate more effectively. Producing a single framework and runtime also ensures that developers have consistent experiences with .NET. Furthermore, taking the best parts of existing .NET components will expand its capabilities in the future. For example, Microsoft continues to collaborate with Xamarin on the Mobile Blazor Binds project, which will use Blazor to develop native UI. These efforts include building a hybrid UI for native apps, although Microsoft isn’t providing details at this time.


Blazor is a major part of Microsoft’s efforts to unify .NET under a single platform. It allows developers to create apps in C#, which doesn’t require interpretation like JavaScript. This difference provides C# with a performance advantage compared to JavaScript. Blazor’s ability to handle both client and server-based apps is another benefit over the aging .NET Framework.

A .NET consulting firm can build a .NET app with various editions of Blazor, depending on the app’s position in the client/server spectrum. The availability of these solutions is complicated by the fact that Microsoft is developing them with a considerable amount of independence from each other. This uncertainty should be largely resolved in late 2020 with the release of .NET 5 and deprecation of .NET Framework.

Posted in .NET Consulting