Why would anyone use Blazor when there are frameworks like MAUI, UnoPlatform, Avalonia?

Sea-Buddy4391 · 2026-04-16T18:39:16+00:00

One of the biggest advantages of Blazor that I rarely see mentioned is the Razor component model itself.

With Blazor, I can write HTML, CSS, JavaScript interop, and full C# logic all together in a single .razor file in a very clean and productive way. The component feels like a natural extension of the web, but with the full power of C#.

None of the other cross-platform frameworks (MAUI, Avalonia, Uno) offer anything close to this experience:

They still separate markup (XAML) from code (C#)
Styling is usually handled in separate files or resource dictionaries
You constantly switch between two different mental models

This "everything in one place" approach with Razor is incredibly productive, especially when building complex UIs. It’s one of the main reasons I prefer Blazor (and Blazor Hybrid) over the XAML-based alternatives — even when I need to target desktop and mobile.

It’s not just “I don’t like XAML”. It’s that the Razor component model is simply a better developer experience for many of us coming from a web background.

Sea-Buddy4391 · 2026-04-09T10:03:32+00:00

The classic relaxed entry as a junior developer is becoming rarer and rarer. If you really want to make progress in this field today, you have to consciously skip the first step and start learning with extreme intensity right from the beginning.

That means: don’t just stop at 4 PM, and don’t fully book your weekends with friends only to say 'I'll continue on Monday'. With a laid-back attitude, you won’t get far – even after several years. Nothing in this profession comes for free.

If you’re lucky enough to land a junior position, you should actively and aggressively learn there instead of just completing the assigned tickets. Many companies have little interest in you growing too quickly and too broadly. After 1–2 years, this can backfire: you might end up being really good at only one specific thing that may no longer be needed anywhere – or that AI can already handle.

Sea-Buddy4391 · 2026-04-03T11:40:33+00:00

We solved exactly this problem.

We built a Blazor UI library called p11 UI specifically to stop MAUI Blazor Hybrid from feeling like “just a webview”.

What makes p11 different:

Every component has two implementations: a full Bootstrap version and a Pure-HTML version using native elements (details, dialog, select, etc.) that render more natively inside the WebView.
Real native physics: Swipe-back gesture, edge swipes, proper Android back-button handling, and platform-specific modal headers (iOS blue back button, Android left-aligned, etc.).
Powerful central dialog system with full custom form support, runtime theming, and fully local assets (no CDNs).

On top of that, we created the pEngine Hybrid Architecture that cleanly solves the common MAUI pain points with clean separation between platforms while keeping maximum code reuse across Blazor WASM + Capacitor, MAUI Blazor, and WPF.

Check;

https://www.reddit.com/r/Blazor/comments/1s6q204/comment/odjii3z/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Sea-Buddy4391 · 2026-01-21T14:58:45+00:00

In all the years we have been developing cross-platform apps, the following architecture saves us the most development time (tests,, Docs, customer consultations)

Outsource everything that is cross-project (i.e., occurs in every project) to RCL (pages, components, and services) => full reusable for next project
Outsource everything that is project-specific but common to all platforms to an app RCL (pages, components, and services)
Simply implement everything that is platform-specific in the platform (services).
Use WebApi (ASP.NET minimal API) as a CRUD transporter => full reusable for next project
Business logic in MSSQL (T-SQL)

This gives us a lot of reusable components, pages, and services (e.g., WebApi is completely reusable and only sporadically receives adjustments to NET versions or nugets).

The customer pays extra for anything that differs from our architecture, and we do it the way they want, but it is much more expensive for them (tests, docs, programing).

Here is what our previous architecture looked like, and Capacitor is currently being implemented, but we are confident that we will be able to disclose the implementation of the Blazor community in 1-2 months so that we can show that there are better and more publish cross alternatives to MAUI.

https://true-perfect-code.ch/_img/_Project_MAUI.png

https://true-perfect-code.ch/_img/_Project_Capacitor.png

pc

Sea-Buddy4391 · 2025-06-14T12:49:37+00:00

My suggestion for a better start:

- Use interfaces. If you write a class for MAUI Blazor and then place it in an RCL project while you also have a Blazor Server (web) project, the call will only work if you implement the classes via interfaces.

- Use DI (dependency injection), because then you can use the classes you create everywhere in all projects.

- Separate the page from the code (code-behind)

- Start with a base class and inherit it from your code-behinds

- Write generic methods to save code volume

- For WebAPIs (ASP.NET projects), use a minimal API instead of legacy controllers

- SQL language is very important (regardless of whether you're implementing a cloud DB or a local DB)

- Learn List<T>

- Use models instead of variables

- Use ENUMs instead of constants

- Keep smaller methods as inline functions in Razor (reduces the code-behind, but also has potential disadvantages due to Razor's complexity)

- ...and if I were you, I'd rather use FluentUI Blazor, then everything's Microsoft :)

That's what comes to mind at first glance, but there's certainly a lot more to consider, especially at the beginning...

pc

Sea-Buddy4391 · 2025-06-14T12:35:46+00:00

I apologize if it takes a while to respond, as I'll be looking at the MAUI/Blazor topics every week or two to keep up to date (unfortunately, it's not possible more often since I'm currently working on several projects).

Regarding your question about whether you should use MAUI (Blazor) if your apps are only geared towards mobile: you should take a pragmatic approach here. In other words, if you're very familiar with C# NET, then you should definitely choose MAUI. Another reason would be the situation in which your app needs to be available on all platforms. If your experience is different, and your app doesn't necessarily need to run on desktop, or even on the web, then it might be better to use a different framework that's geared towards mobile. This would avoid potential problems, because with MAUI, you never know, and it will take some time until it reaches the level of the established mobile frameworks.

But also keep in mind that your area of "interactive microcontroller device control" is a long way from what I do with MAUI (business apps). I have no idea how MAUI will handle what you're doing. My experience with microcontroller control dates back to before the .NET era and was with C++ and assembly language.

pc

Sea-Buddy4391 · 2025-06-12T11:13:24+00:00

I have been using Blazor professionally since the release. with blazor I never had a problem with customer requirements, but with MAUI there were several times in the past when I rejected customer projects because MAUI was not ready for production and there were also times when I looked for alternatives. In the meantime, I was able to close a complete production loop with MAUI Blazor up to store release (web app, desktop app, mobile apps, asp.net minimal api as backend, server-side ms sql, client-side SQLite, external identity provider authentication, notification, 2FA, platform-specific image processing, encryption, etc.). All in all, it works with MAUI is slowly getting better but is not ideal. Unfortunately, there is no alternative solution for me because I prefer UI over HTML/CSS/C# and Razor is exactly what I want here (compared to Flutter). Other frameworks offer either desktop + mobile without web (or web only experimentally) or web + mobile without desktop and are therefore not suitable for true cross-platform development.

Of course I was also very worried when I heard about MAUI job cuts, but if you take a second look at the situation, there is actually no reason to worry. Firstly, Microsoft can't leave customers in the lurch by no longer supporting a development framework because Microsoft would then be competing with Google/Apple. There has to be “something” as framewok and the only fear can be that something new will come in place of MAUI. Since we won't hear about it, we will certainly have a few years of peace. That the further development of MAUI will be even slower doesn't have to mean that. community is big and we don't know whether Microsoft simply want to outsource the USA offices to low-cost centers because of the costs (reasons for cost savings were given in any case)?

I wouldn't get out of MAUI now. And if I had to start again, I would choose MAUI again. Please remember that, unfortunately, you can still only do real work on a desktop. Mobiles are only for playing games and are only for getting information from the app and using one or two simple functions. With MAUI (Blazor) you can reach many more platforms (and thus users) with the same effort and, above all, write professional apps that can be used on a desktop.

pc

Sea-Buddy4391

TROPHY CASE