Q&A

Q&A: Deep Dive on Blazor

• By David Ramel
• 05/09/2022

The "hottest" project in the Microsoft-centric web-dev space is Blazor, which offers both a server-side component and a client-side component based on revolutionary WebAssembly tech, combining to provide a C#-based experience instead of JavaScript.

The free, open source framework has evolved from its web focus to target other realms, including mobile and even desktop.

Officially, Microsoft says:

Blazor apps are composed of reusable web UI components implemented using C#, HTML, and CSS. Both client and server code is written in C#, allowing you to share code and libraries.

Blazor is a feature of ASP.NET, the popular web development framework that extends the .NET developer platform with tools and libraries for building web apps.

With its growing popularity in the Microsoft dev camp, it's no surprise that it's the subject of a deep-dive feature presentation at the upcoming, in-person Visual Studio Live! conference set for June 13-17, 2022, in Austin, Texas.

Leading the deep dive is Rockford Lhotka, a well-known open source and distributed systems architect, author and speaker. We caught up with "Rocky" for a short Q&A to learn more about his presentation that will teach attendees:

• How Blazor, WebAssembly, and .NET combine to enable this app platform
• How to build server-side Blazor and Blazor WebAssembly apps
• How to use Blazor UI framework features such as UI components, data binding, routing, and authorization

VisualStudioMagazine: Since its roots as a Steve Sanderson pet project, Blazor has become enormously popular. In addition to letting C# coders get in on the web-dev action instead of primarily relying upon traditional mainstay JavaScript, what else does Blazor offer to account for that popularity?
Lhotka: Blazor provides a number of powerful features beyond enabling C# developers to use their language of choice for web development.

Blazor supports running your code on the server or on the client via WebAssembly, and you can choose which users or devices get either experience. For example, you may route users with older, less powerful devices to use server-side Blazor, and users with modern devices to use Blazor WebAssembly.

Blazor also includes a powerful UI component model, based on learnings from previous UI frameworks such as MVC, Web Forms, Windows Forms, WPF and Xamarin. The Blazor UI component model makes it easy to create highly maintainable and reusable UI components surrounding a single UI widget or entire sections of app functionality. Coupled with the simple, but extremely powerful data binding capabilities supported by Blazor, the result is a UI model designed for creating apps at an enterprise level all the way down to a simple web page.

ASP.NET Core MVC is also less reliant upon JavaScript than other alternative frameworks. Does Blazor offer advantages over ASP.NET Core MVC, or are they specific tools for different types of jobs?
ASP.NET Core MVC is a server-side web framework, with roots going back to the days leading up to what we now think of as the modern web. For some app scenarios, a server-based model that pushes HTML, CSS and JavaScript to the browser is still very valid. This is particularly true for scenarios where data display is important, and user interactivity is of secondary importance.

For apps where user interactivity is highly important, most people favor UI frameworks like Angular, React or Blazor. All of these toolsets provide the ability to create rich user experiences, though none are as efficient at raw data display as something like MVC.

The advantage of Blazor in this case, is that you can intermix ASP.NET MVC or Razor Pages functionality right alongside your Blazor functionality all in the same app and using the same IDE and programming language.

From its initial focus on SPA apps, Blazor WebAssembly has been pointed at all kinds of other targets, from mobile to even desktop. Is there a limit to this? Why not Blazor for everything?
WebAssembly itself is likely to be a transformative technology across many app types, because it runs in all modern browsers, and an increasing number of server-side and IoT scenarios, including places like Kubernetes. The ability to write code in your language of choice, such as C#, Go, Rust or many others -- and have that code compile to WebAssembly so it can run across so many environments -- is extremely compelling.

Blazor WebAssembly itself is a UI framework focused on leveraging HTML and CSS, plus your C# code (instead of TypeScript or JavaScript) to build browser-based apps. As with other SPA technologies, Blazor benefits greatly from the expansion of browser-based hybrid scenarios for hosting on mobile and desktop apps, as well as directly in a browser experience.

What all these have in common is that the browser sandbox remains in place. This is good, because it means that Blazor WebAssembly apps can be run in your browser or as a mobile or desktop app with the same security and confidence you have with apps written in other tools that target the browser, such as Angular or React.

On the other hand, it is often most cost effective to build very high-fidelity mobile apps using more native technologies as compared to browser-based technologies. If you are creating a consumer-facing mobile or desktop app that is a primary touch point for your brand, it is obviously critical that your users get the best possible experience, leading most organizations to create native iOS and Android apps, or maybe to use a cross-platform tool like Xamarin/MAUI or Flutter.

Do organizations usually combine Blazor Server and Blazor WebAssembly functionality in their development, or have you found one or the other to be more prominent?
In my observation, many organizations are using server-side Blazor, with the understanding that if they need the scalability provided by Blazor WebAssembly that they can embrace that model in the future. Slightly fewer organizations are building Blazor WebAssembly apps from the start, and a minority are building their apps to dynamically switch between the two models at runtime.

How about performance? How does Blazor compare to alternative frameworks like React and others?
When talking about Blazor performance it is necessary to separate server-side Blazor from Blazor WebAssembly.

Server-side Blazor is extremely performant, with performance largely based on making sure your web server is sufficient for the workload. The software architecture behind server-side Blazor is extremely similar to the time-tested models used by VT or 3270 terminals of days gone by, but with modern internet speeds and server hardware.

Blazor WebAssembly, or any WebAssembly-based UI really, may be slower than JavaScript UI frameworks such as React. This is because WebAssembly does not yet allow native code to interact directly with the HTML DOM, so interaction with UI elements must go through a JavaScript shim. Pure compute code tends to be faster in WebAssembly than in JavaScript, but UI interactions are slower.

You should temper this with an understanding that, when used correctly, all these SPA UI frameworks, including Blazor WebAssembly, can create user experiences that are top-notch and very satisfying to use.

What innovations do you see coming for Blazor and its backing client-side tech, WebAssembly?
I look forward to WebAssembly embracing multi-threading and having the ability for native wasm code to directly interact with the HTML DOM. I am also extremely excited about how WebAssembly is spreading beyond the browser, with the potential of becoming a common assembly language for the client, servers, IoT devices and more.

Blazor is poised to support multithreading, and with its tight integration with the MAUI framework, Blazor is likely to become a major technology for creating apps that run in browsers, on mobile devices and on desktops, all based on largely the same C#, HTML and CSS codebase.