WinUI vs Electron & Blazor Vs Maui

Introduction

This post focuses on some of the current options available for multi-platform software development. Blazor with Maui, WinUI with Webview2 and Electron with Blazor are all considered. Please note that at time of writing Blazor and Maui are currently in preview.

The Requirement

I need to build an app that will act in a similar way to OneDrive. It needs to have the following:-

• Ability to minimise to System Tray
• Interaction with Toast Notifications via the Notifications API
• Multi platform support
• Ability to reuse pre-written React components
• Has to allow for development in C#, JS. Xaml can be used. Essentially, something that a mid-Senior development team can take forward.

Please note that any business context will not be included, along with any code relating to that.

Option 1 – WinUI with WebView2

Following the “Getting Started” guide I quickly realised that a quick “paint by numbers” tutorial wasn’t going to go as easily as I anticipated. Just trying to build the app following Microsoft’s own instructions resulted in build errors. In part due to the incorrect WT runtime which can be fixed by specific framework targeting in the csproj file. I’d also hit a bit of a brick wall in a previous afternoon out with WinUI development relating to an error with Tokens and Azure Notification Hub

It soon became apparent that using a WinUI approach wasn’t going to present the requirements exactly as I envisaged. A “system tray” approach isn’t supported. This could be over come by using the windows “JumpList” but obviously this UX just doesn’t feel right. I guess the better approach here would be WinForms. I realise that either using WinUI or WinForms I’m breaking one of my own requirements for Multi platform. So, lets crack open MAUI…….

Option 2 – Maui with Blazor

At time of writing and proof of concept Maui is in preview along with .Net 6 – due to land as GA and LTS in November 2021. On paper this looks ideal. Full multi-platform support, BlazorWebView along with the ability to target and “roll your own” native implementations.

I’ve already played with Blazor and been suitably impressed with the flexibility it offers and the lack of Javascript 🙂 . It quickly became apparent that this approach would offer each requirement I needed and although this is in preview currently (with monthly bug fixes from now until November) it’s certainly progress that any developer should keep an eye on.

It was interesting to see that some of the native implementation out of the box comprises of existing code that has been around for years. For example, there’s code lifted from NotifyIcon to handle the native windows system tray. There’s also ResizeTizer to handle the resizing of icons to target the different platforms and viewports.

Option 3 – Electron With Blazor

This is where things are starting to look a little tired now. Whilst Electron with Blazor would give the same offerings as Option 2 it does have some downsides mainly:-

• The footprint of the published app. Even my proof of concept with little included was weighing in at over 100Mb.
• Another technology to learn that appears to be dying. Developers seem to be turning their back on Electron. Understandable as Microsoft are investing heavily in this area. For example, there’s little benefit in working with Electron’s wrapper around toast notifications when you can easily plumb in Microsoft’s Nuget offering

Winner – Option 2

No contest really. The blend and power of BlazorWebView with Maui offers a real solid tech stack for future development. The testing options look tasty also in the form of Bunit for testing Blazor components and also Verify for rendered snapshot comparison.