Q&A: Deep Dive on Blazor
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.
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
Lhotka: Blazor provides a number of powerful features beyond enabling C# developers to use their language of choice for web development.
“Blazor provides a number of powerful features beyond enabling C# developers to use their language of choice for web development.”
Rockford Lhotka, Chief Software Architect, Marimer LLC
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.
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.
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.
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.
David Ramel is an editor and writer for Converge360.