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.
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).
Which is where Blazor comes in.
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
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).
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
Which raises the question: If CSB works, why isn't it supported in production?
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.