40
Blazor Desktop: Like Electron for Javascript but… for .NET?
Not too long ago, Blazor WebAssembly was just a runtime experiment for C# in a Microsoft web browser. Knowing Microsoft, which has left many large corporate projects behind, it was not known what to expect from Blazor. As time passed, Blazor became a real project and went into production in record time. Now all the rumors are running around Blazor Desktop.
In mid-February, Microsoft released the first LTS preview version of .NET 6 for release in November. Their presentation talked about Blazor Desktop, but what confused the developers the most was that they failed to mention that the .NET 6 preview version did not include that feature.
The question we ask ourselves at this point is…
What really is Blazor Desktop?
Microsoft likes to compare it to Electron, which is the desktop container for JavaScript applications, with which applications like Slack work. Electron today is still quite popular despite its problems and the most curious of all is that it is developed by GitHub, which is owned by Microsoft.
The point is that Electron is not only used to execute JavaScript code for web pages, but it also has a self-hosted version of Node.js and a wide variety of extensions that provide JavaScript applications with desktop capabilities. As we know that there is no equivalent in the world of Microsoft…
What would a Microsoft-style Electron for Blazor look like?
The answer is WebWindow
WebWindow is an experiment by Steve Anderson who tried to create a lightweight container to host Blazor applications. In recent days, Microsoft has dropped that Blazor Desktop is inspired by WebWindow.
To get used to the idea, WebWindow does what its name suggests:
Desktop window that displays the web user interface. This is generated from the operating system itself, to give an example, WebKitGTK would be used in Linux, WebWiew2 in Windows and WKWebView in MacOs.
You may be thinking right now that it is not innovative to see a web page in a desktop window. But it is not the only function of WebWindow, it also has a hosting model to run Blazor applications.
The first big difference is that the WebWindow container doesn't use WebAssembly. You can run the same Blazor application in WebWindow in the same way as on a web page. But when using a web page, it runs with a lightweight .NET Runtime that works with WebAssembly. When you do the same in WebWindow, the cross-platform .NET Runtime will be used directly. This ensures that a native runtime will outperform the hosted version of WebAssembly.
The second big difference is that in a Blazor Desktop application hosted in WebWindow there is no integrated web server, in this case it uses .NET 100%. Although at the moment we have not seen how this will be implemented, but if everything goes according to Microsoft's plans, it would be like using Electron without the need to learn Node.
All of this raises a pretty obvious question…
Why use Blazor Desktop if you could just build a cross-platform application in .NET?
The problem with all this is the front-end, since .NET 5 offers many tools for the user interface (UWP, WPF, Windows Forms) but there is not one that works on any other operating system than Windows. Blazor Desktop will allow you to program the backend using the .NET Runtime that we talked about before. This would be combined with the Blazor UI model, then I would work through WebWindow to manage the UI.
It's still early, but let's do a summary of the possible features of Blazor Desktop:
- Smaller discharge size than Electron
- Less memory overhead than Electron
- Desktop application system with cross-platform web user interface
- Better native performance than Blazor WebAssembly
Well, you should be comfortable with the Blazor application model, as it has a lot of influence from ASP.NET Razor and does not resemble any of the tools for Windows .NET applications.
And not only is it, Blazor Desktop is just a consequence of .NET MAUI, a framework to bring desktop user interface models closer together. There is also a possibility to use WebWindow to create hybrid applications that combine the content of various user interface tools. To give an example, imagine a window with WPF controls next to a Blazor content region.
It is clear that in the same way that thousands of people will love this, many of them will not. Most developers keep wondering why we are still chained to the HTML and CSS model as a rendering surface for every user interface we create. Many of them also dream of a new fast writing and rendering UI framework (based on something like XAML).
What the experience of a web model has shown is that with native extensions it is much easier to create a new user interface model. Although if you expect something better, you still have Flutter from Google.
In the meantime, we can only hope that .NET 6 will give us more reliable ways to develop web-like desktop applications on any desktop, running in a familiar runtime and written in full C#. Of course, that possibility did not seem viable a few years ago.
40