Let’s Learn Blazor
ASP.NET Core’s Web Front End Platform for .NET Developers
This is one of several articles on Blazor I’ll be writing, all so engineers can get familiar with the capabilities and tricks of this burgeoning and exciting web technology
Preface: UI Hell for a backend developer
Way back in the day (the late 90s), I was a front-end architect. My team and I built a front end app which could have been thought of as a first attempt at building a front-end application framework which would look very much like today’s JQuery. Frankly, we were way out of the bleeding edge.
We were using IE 6’s newly-released MSXML 3.0 and DOM 1.0 capabilities, and at the time very few companies were so far down the client-side web development road. What we were building back then was definitely out there and impressive for what was available at the time. Manipulating the ECMAScript DOM, dynamically building and binding backend data via XML / XSLT to UI elements, front-end validation components and libraries, the works. We had to work around a lot of the limitations of early Javascript as well as the shortcomings of browser support. But what we created was an impressive feat and all of us were super proud of it.
After leaving that company to move overseas, I left front-end development behind, turning my attention on backend / API development, and there I’ve been for quite some time.
On a recent API project, it was clear I needed a front-end for the API to be useful to my company. After pestering a number of the React developers for assistance, I got that everyone was too busy with their own work to help me out. All good. I decided to give it a go and try my hand at React.
It did not go well.
Perhaps it’s all the years in backend development. Maybe it’s my love of the simplicity and power of .NET Core and how easy it is to build and debug so quickly. Also likely is the fact that getting any kind of Node.js application up and running is a far more convoluted process than anyone is willing to admit. Asking one hundred devs online how you configure your Node.js app to transpile from Typescript will get you one hundred different answers. The cacophany and bloat of NPM packages to do the simplest things is enough to make your head spin.
After fighting for a week to get the basic scaffolding of a React app up and running, I got to cutting code. I knew quickly this wasn’t for me. Building in React just didn’t jive with my development paradigms. I didn’t care for the syntactical looseness of Javascript. The difficulty in wiring things up and making them work together felt painfully hard. I didn’t find the development pleasant, just a struggle to accomplish things which should have been very straightforward.
I’m not saying React is bad, just that it’s bad for me. Everyone has their preferences, and if React / Node.js is your thing, more power to you. For me, it was awful. After less than a month of fighting the React / Node.js / NPM demons, I gave it up as a lost cause. I know enough to know when I’m beaten.
That same week, I was having a pint and a moan about the entire experience with a dev pal, who suggested I give Blazor a go.
I’d heard of Blazor, but hadn’t looked at it in any way, but given how terrible things were going with React, I figured it couldn’t hurt.
What is Blazor?
From the Microsoft docs:
Blazor lets you build interactive web UIs using C# instead of JavaScript. 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.
Okay, more my style. So how does it work?
Blazor can run your client-side C# code directly in the browser, using WebAssembly. Because it’s real .NET running on WebAssembly, you can re-use code and libraries from server-side parts of your application.
Alternatively, Blazor can run your client logic on the server. Client UI events are sent back to the server using SignalR — a real-time messaging framework. Once execution completes, the required UI changes are sent to the client and merged into the DOM
Let’s break this down to plain speak.
You have two primary choices for running your Blazor app:
- A client-side application built using C#, HTML and CSS which is run in the browser after compiling to the WebAssembly Open Standard. WebAssembly-compliant compilers allow you to build applications in languages other than Javascript and have them rendered and run in your browser much the same as a Javascript application. They live in the same sort of sandboxed security spaces as Javascript apps, and enforce same-origin and security policies as the browser.
- A server-side application built using C#, HTML and CSS, yet which communicates with the Blazor pages and components rendered in the browser DOM via SignalR Core. This is all handled automatically, so you build your backend web code, your Blazor pages and components and then the Blazor Server-Side functionality automatically handles their client-side communications.
While both are compelling for different reasons, the power of Server-Side Blazor is that back-end developers familiar with ASP.NET Core MVC and Web Apps are already pretty close to the technology at hand. With some minor caveats in terms of how you do things (such as IoC injection in your Blazor pages), most of the skills a .NET backend developer has will translate 100% to a Blazor Server-Side application.
Blazor UI Language: Razor
Another win for existing ASP.NET Core developers is that Blazor’s UI language is based on Razor, the well-known .NET markup syntax. Razor has been around since 2011, first released as part of MVC 3, and so is well-known in the industry.
With clear exceptions, the Razor syntax you may have written for an older MVC or Web Application can be re-used in your Blazor application, especially where Razor components are concerned. This is a further benefit as no one wants to spend the next five years rewriting their existing applications from MVC over to some other web technology. Server-side Blazor is a good match for this use case, and a great way for a development team to port older code to greener pastures.
Beyond the Browser: Blazor Desktop
If the Client-Side and Server-Side Blazor weren’t enough, Blazor is already in preview to run in desktop applications. As of .NET 6, Blazor Desktop has been released, allowing you to build desktop applications using Blazor.
You can do this in a couple ways.
- You can now embed your Blazor apps inside of Electron, the highly-popular cross-OS desktop framework. This is evolving as part of the Electron.NET project on GitHub.
- For those who are more cutting-edge, you can have a look at Blazor mobile bindings, the ability to build native mobile apps using Blazor.
All of this desktop and mobile capability for Blazor is being driven by .NET MAUI, a framework to bring desktop user interface models closer together.
While all of this is very much preview at this stage, it does begin to show you the power of Blazor and what you’ll be able to do in the coming months and years. Building applications for different platforms is — quite frankly — a bloody horror show. If it were possible to build various applications using much of the same code but targeted to various platforms / devices, the pain would become drastically reduced.
Coming up next
In the next session, I’ll take you through building a simple Client-Side (WebAssembly) Blazor app and how you get it published and ready for use via the dotnet CLI.
Hope this helps.
