1/15/2020
Blazor is Microsoft's cross-platform technology for creating client-side, browser-based applications in C# using .NET Core. It really does work and, more importantly, really could change everything.
The immediate reason that IT shops should be interested in Blazor is because it reduces the size of the shop's toolbox. The long term reason that you want to look at Blazor is because it provides an entry point for a single toolset to deliver applications on any platform: Windows, Unix, Andriod, Mac, and iOS.
That matters because, right now, if I want to build a modern Web application with Microsoft tools, I'm going to use ASP.NET Core and C# for my server-side functionality (both for building pages and delivering Web Services) and JavaScript to build my client-side functionality. For anything but the simplest client-side applications, I'm also going to leverage one of the popular client-side frameworks - probably Angular or React. If I expand out from Web-based applications, I'm going to stick with .NET Core and C# but I'll also need to look at some desktop technology (WPF?) and, if I want to create native mobile applications, Xamarin.
What's Wrong
From my organization's point of view having two technologies is too bad, especially because of the technologies involved: JavaScript and C# don't have a lot in comment (well, other than using a lot of curly braces).
C# is a data-typed language and that data typing significantly improves programmer productivity while making it more likely that bugs will be caught before they get into production. JavaScript, on the other hand, isn't data-typed. That gives developers a lot more flexibility than they can get with a data-typed language...including more opportunities for bugs and errors that won't be caught until the application is up and running.
In addition, C# is an object-oriented language; JavaScript, on the other hand, is organized around the concept of the prototype (in fact, most of the recent enhancements to JavaScript have been to try and give JavaScript some of the features associated with object-oriented programming). Moving from C# to JavaScript doesn't require a complete brain replacement...but it helps.
This creates two problems for the organization. First, the organization has a larger toolbox than it would need if the same tools worked both on the client and the server; Second, because the toolsets are so different, it's difficult to move resources between the client and server side environments (both staffing and shared code/technology).
The Solution
Which is where Blazor comes in.
Blazor both is and isn't a "Microsoft product." Blazor is based on a W3C standard called Web Assembly (usually referred to as "wasm"), introduced as part of the HTML5 specification. Wasm provides a way for sites to download and execute code that isn't written in JavaScript - C# and .NET Core, for example. Because it's based on industry standards, Blazor runs on any current Web browser.
With Blazor, Microsoft has leveraged the wasm standard to build a client-side framework that provides many of the features that developers get with Angular and React. Blazor allows developers to:
- Build reusable components that can work together to create complex single-page applications
- Integrate code in those components with HTML to build sophisticated user interfaces
- Allow users to navigate from one component to another within an application
Plus, Blazor makes it easy to integrate components written in C# with JavaScript: C# can call JavaScript code and JavaScript code can call C# code (though that's becoming increasingly unnecessary as Blazor evolves).
The Two Versions: Server-Side Blazor
However, there are currently two versions of Blazor, only one of which is supported for production by Microsoft (since November of 2019): Server-Side Blazor (SSB).
With SSB a Microsoft-supplied JavaScript library communicates with Blazor code that's actually running on the server. Because it executes on the server, with SSB, if I need to access a server-side resource (e.g. a database) I can just call it directly. Obviously, there are some downsides here: Network latency as messages go back and forth between the browser and the client, plus the possibility of losing the connection altogether. Under the hood,
Blazor uses another W3C standard (WebSockets) to implement this connection so those messages are running over TCP/IP just like any other network traffic. That reduces the network latency issues but replaces them with capacity issues: There's going to be some limit to how many simultaneous WebSocket connections a server can maintain (though if that's more than the maximum number of simultaneous users you have, then the issue is irrelevant). Blazor has built-in support for handling poor connections but, if this is a concern for you, you might want to restrict Blazor to intranet applications within your organization.
The Two Versions: Client-Side Blazor
The other, "not-yet-supported-in-production" version of Blazor is Client Side Blazor (CSB). With CSB, all the necessary code is downloaded to the browser and executes on the user's computer. With CSB, if you need to access a server-side resource then, just like JavaScript, you must call a Web Service...though, of course, with Blazor you call a Web Service from the browser with exactly the same code that you'd use on the server.
Which raises the question: If CSB works, why isn't it supported in production?
The primary issue is the size of the package that has to be downloaded to the browser. In the current version of CSB that download size is about six megabytes. For comparison's sake, the download for Angular is about an eighth of that. As a result, the start up time for a Blazor application is significantly longer than for an Angular or React application (or, really, any JavaScript-based application).
There is a solution here: It's called Ahead of Time (AoT) compiling. Microsoft expects that to be working by May of 2020 when CSB is scheduled to get full production support. That's right around my birthday and I couldn't expect a better present.
When to Start Using Blazor
So, right now, you can use SSB for intranet applications. You might even be willing to experiment with SSB for Internet applications. If you're willing to live with the startup times there's nothing stopping you from using CSB right now in either environment
Or you could start with Server-Side Blazor right now and then convert to Client-Side Blazor when it's released. The code you write in CSB is identical to the code you write in SSB: The only difference between the two is that you can't directly access server-side resources in CSB -- you have to go through a Web Service. If that's a path that you're considering there are two strategies you can follow:
- Isolate your data access code in separate classes so you can easily replace that code with Web Service calls when you migrate from SSB to CSB
- Write your server-side code using Web Service calls right from the start (remember that, on the client, Blazor uses exactly the same code to access a Web service as you use on the server)
And, of course, if you start with Server-side Blazor you may find that you have no network latency problems, no WebSocket capacity issues, and no lost connections (I haven't, for example). If that's the case, you might as well stick with SSB even after CSB becomes production ready (the "if it ain't broke, don't fix it" pattern).
Blazor's Future: Single Tool, Every Platform
But there's more.
Ideally, we would all like to have a toolkit that allows us to deliver applications to any platform. Microsoft's .NET Core goes a long way towards that by delivering to both Windows and Linux. Microsoft also has Xamarin Forms which allows developers to deliver create an application that runs on both Android and iOS using native UI widgets (and enabling the application to access any platform-specific functionality). All of this is enabled through the .NET runtime which has versions for each of these environments.
Blazor completes that toolkit because it's actually very loosely coupled to HTML - Microsoft designed Blazor to make it relatively easy to use Blazor with any UI tool. So, in 2019, Microsoft rolled out a roadmap for Blazor in 2020 that begins with Web applications...and ends with native UIs any platform (here's a summary of the Microsoft presentation on that roadmap with a link to the presentation). And, sure enough, on January 16th, 2020, Microsoft took the first step towards Blazor linking with Xamarin Forms to create native mobile apps both for Android and iOS.
Microsoft has all the tools and products to provide a genuine cross-platform development toolset that still allows developers to access platform-specific functionality. Blazor isn't just at the center of integrating the Web development toolkit, it's at the center of integrating all of your development toolkits. And that's just by the end of this year.