Blazor is new. So new, in fact, that it’s only a beta preview in the latest version of .NET Core (3.1). The true first release of Blazor — or to be more specific, Blazor WebAssembly, the technology that lets C# run in a WebBrowser — is scheduled for this May.
The quest for universal UI
For years, .NET developers have been clamoring for a way to build cross-platform user interface. In a perfect fantasy world, that means being able to build a single front end that works for web, desktop, and mobile apps.
Microsoft’s most mature toolkit for rich desktop development (WPF) and their solution for native mobile apps (Xamarin) are tantalizing similar. Both define user interface using the XAML markup standard. Both are oriented around data binding and support the MVVM pattern. But despite these similarities, there are problems. WPF is tightly bound to DirectX and other key parts of the Windows operating system. And even if WPF and Xamarin did converge, there’s still a mismatch between XAML-based UI and the HTML markup of the web.
There have been attempted solutions (the open-source Uno comes to mind), but there’s nothing that’s an official, Microsoft-supported part of the platform. Google has its Flutter toolkit. But Microsoft has a yawning gap between the worlds of mobile, desktop, and web.
Recently, I wrote that this void might not be an accident. Maybe Microsoft is waiting — resisting the urge to fill the space until it has the right replacement. And maybe that replacement is an evolved version of Blazor.
A Blazor background
If you’re still catching up with Blazor, here’s a quick recap: Blazor is the name for two different technologies that let you write rich browser-based applications that run .NET code.
Let’s assume that Blazor WebAssembly reaches its full release and does what it says on the tin — in other words, it gives .NET developers a way to run C# in the browser. That’s impressive enough. But where might Blazor go next? Microsoft is starting to hint that a few of its experimental projects aren’t just experiments any longer. The first example is Blazor desktop applications.
Blazor on the desktop
Microsoft is working on a experimental project that puts Blazor inside Electron. But instead of using the full Electron package, it’s trying different ways to slim things down. One approach is WebWindow, a lightweight web page harness that uses the web support built into desktop operating systems. Here’s how it works when you run an application:
- WebWindow launches a native desktop window (on any operating system)
- The entire window is filled with a web page
- The web page loads up your desktop-enabled Blazor application
There are other frills, too. The application’s download size becomes a mere fraction of a full Electron app. And you can easily turn the Mac version of your application into a traditional, installable app bundle with a proper icon.
So far, these experiments have had severe disclaimers (“This library is super-pre-alpha quality” and “So far, this is just another prototype” and “I’m not making any promises!”). But in the .NET Conf sessions, they appeared in the Blazor Future Features presentation as official possibilities on a distant horizon. Yes, they aren’t practical for production development today. But now they seem less like ideas, and more like plans.
Native Blazor on mobile
Blazor is an obvious choice for building mobile web applications. But what about apps that need better performance or native capabilities like hardware access? The .NET platform already includes an excellent option with Xamarin. Right now, Xamarin is a separate toolkit, but .NET 5 will absorb it into the standard library.
But Xamarin isn’t perfect for the new world that Microsoft is building. From a programming model point of view, Xamarin applications don’t look like Blazor applications. This is a problem for a company trying to create a single development model that can do everything.
One possible solution is Mobile Blazor Bindings, an experimental project that Microsoft announced for the first time at .NET Conf. The goal of Mobile Blazor Bindings is simple: allow developers to build an application using the Blazor page model, while accessing the features built into Xamarin. (If you’ve never played with Xamarin before, it has a library of features with cross-platform implementations for Android and iOS.)
With Mobile Blazor Bindings, developers get to create something that looks a lot like a Blazor app, but still uses Xamarin’s support for native UI and device-specific features. It isn’t close enough that you can create a single UI for mobile devices and web applications. But the gap is narrow — so narrow that a developer who’s created a Blazor WebAssembly app will feel immediately at home building a native application with the Mobile Blazor Bindings. Eilon Lipton demonstrates a sample app here.
What lies ahead