One of our Senior .NET and front-end technologies instructors talks about cross-platform development and specifically Blazor.
Ever since I started out in software development – in the early Nineties – one of the Holy Grails has been the idea of cross-platform development, sometimes known as WORA: Write Once Run Anywhere.
Back then, the two platforms we were most concerned with were VMS and Unix. Now, the platforms are different, but the problems are the same, if not worse. We need to write applications for, at the very least, Windows, Android, iOS and macOS. And we need to design User Interfaces that work on a range of devices from a mobile phone through to a desktop machine with a 4K screen.
In the .NET world, a big step forward came with the introduction of .NET Core in 2016. This allowed .NET installation on a wide variety of devices with a minimal footprint. But there was a drawback: the only style of User Interface you could write was a console application.
That’s not as big a problem as it might sound. A console application can be a web server and thus the issue of a user interface can be devolved to the browser. The job of making browsers run on multiple platforms is the responsibility of their manufacturers, and site developers just have to deal with standardized languages such as HTML and JavaScript.
Better still, since 2018 you can use Blazor (a somewhat forced portmanteau of ‘Browser’ and ‘Razor’) to program your browser in C# instead of JavaScript. You’ll still need to know some HTML, but you mix it with C# using Razor syntax, which is well-established thanks to older technologies such as ASP.NET MVC.
Blazor operates in two very distinct ways. The first is Blazor Server. All that is downloaded to the browser is a standard JavaScript file, which establishes a bidirectional SignalR connection back to the server. The C# runs on the server and sends instructions via the SignalR link to the JavaScript on the browser, which then generates the appropriate output. This means that there is little work done on the browser, but there is a high overhead of client-server communication.
Blazor WebAssembly is quite different. The C# (compiled down to Common Intermediate Language) is downloaded to the browser where it is further compiled to the recently introduced WebAssembly
language (WASM), which bypasses JavaScript and directly manipulates the browser output.
Given that the two technologies are so different in their approach, it may seem odd that both come under the same banner of Blazor. However, the API is designed in such a way that the C# code for a Blazor Server component is identical to the code for the equivalent Blazor WebAssembly component. Thus, it is not a critical decision which approach to use. Even if you’ve put a lot of development effort into one technology, almost all of your code – and understanding – can be used with the other.
So we have a GUI, but it is still running in a browser. The technology – Blazor, Angular, or whatever – may be different, but the user experience will be much the same.
One solution to this is the Progressive Web Application. With a small bit of configuration, any website can be converted into a PWA. The user then has the option of installing it on their machine, much like any other app. When they run it, it still runs in a browser, but using a window dedicated to that app, with browser specific controls such as the Address Bar, Bookmarks, Back and Forward buttons removed. Thus, the user gets the impression of interacting with a desktop application, even though it is still essentially a browser technology.
In terms of Blazor, a PWA only really makes sense with Blazor WebAssembly. One aspect of a PWA is that it should continue to operate (albeit with some limitations) when disconnected from the server – particularly important on a mobile device. Blazor Server requires a constant connection to the server, so would not be suitable. Blazor WebAssembly runs entirely in the browser, once downloaded, and so is ideal.
Even so, a PWA is not quite the same as an installed application. However well designed the GUI, it is still running inside the browser, and therefore within the browser’s sandbox. The application will not be allowed full access to many of the underlying operating system’s features, such as the file system, or networking, or push notifications. This is an important safety feature for an application that the user does not fully trust, but limits functionality that the user may actually want from a trusted app.
The .NET solution is MAUI – Multi-platform App UI – which allows fully functional .NET GUI applications to run on any platform that supports .NET, but without the restrictions of running in a browser.
MAUI has evolved from an earlier cross-platform library called Xamarin.Forms and also supersedes the Windows desktop API, Universal Windows Platform. It allows for two distinct ways of writing an app. The older, simply called .NET MAUI, uses the established Windows technologies of Windows Presentation Foundation and Extensible Application Markup Language, but applicable to non-Windows platforms.
The other option is .NET MAUI Blazor, where GUI code can be written as Blazor components, meaning that existing Blazor components can be used in MAUI and developers with Blazor experience do not have to retrain to use XAML. In fact, both XAML and Blazor can operate alongside each other in the same application.
But does MAUI use Blazor WebAssembly or Blazor Server?
The answer is neither. MAUI Blazor uses a third approach – Blazor Hybrid. In truth, this is more akin to Blazor Server than Blazor WebAssembly. In Blazor Server the C# runs on the server and instructions are sent to the browser to manipulate the display. Blazor hybrid is much the same, except the server and the browser are both running on the client machine, in the same process, and communicating via a local interop channel, rather than over the internet. The browser is not a separate application, but a XAML control called BlazorWebView, which is based on the Chromium engine.
And with that, .NET developers can finally write cross-platform applications which fully exploit the features of the devices that they are running on. That doesn’t mean that programming MAUI is easy, or that MAUI is the best solution for every type of application.
But it does mean that your .NET code base can now be used across a much wider array of application types. And your .NET developers can apply their hard-won experience to whatever platform is required.
If you found this article interesting you might be interested in our Microsoft .NET training courses.
