.NET MAUI is coming to Linux and the browser
Mood
excited
Sentiment
positive
Category
tech
Key topics
dotnet
maui
avalonia
cross-platform development
.NET MAUI is expanding its reach to Linux and the browser, powered by Avalonia UI, a significant development for cross-platform .NET applications.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
17m
Peak period
153
Day 1
Avg / period
53.3
Based on 160 loaded comments
Key moments
- 01Story posted
11/11/2025, 10:50:32 PM
7d ago
Step 01 - 02First comment
11/11/2025, 11:07:49 PM
17m after posting
Step 02 - 03Peak activity
153 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
11/14/2025, 6:06:30 PM
4d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
I wish we can go back to UIs that focus on information density and usability. I love looking at Japanese websites because of this.
You can check out the Avalonia demo reel to see what you can already do with the .NET GUI stack that MAUI now uses on Linux and on the web: https://avaloniaui.net/showcase
WPF & WinForms are also still around
Canvas rendered cross-platform UI frameworks like Flutter & Avalonia targeting browsers (WASM), might shift the balance back in favor of desktop UI.
If you are building a Windows desktop application though, Microsoft does not want you to use MAUI. You use MAUI because iOS and Android are your top platforms and you want to target macOS and Windows without writing dedicated applications.
Linux has always been missing. This Avalonia port fills that gap.
You would not target the web with MAUI either. I guess "you can" now because WASM is one of the platforms that Avalonia supports. Again, I guess you might if you already have a MAUI app and do not want to create one for the web. But you would never set out to create a MAUI app for the web.
A chrome browser by itself can't work that - it's great for many things, but not for Creative Tools.
Newish low level features of C#: https://em-tg.github.io/csborrow/
Now, I understand that you may talk about it from a non-technical perspective, but even so, there are major differences. C# is a general purpose language for the cloud/web, and so is Go, but Go is also widely used in other areas like in embeded software. TinyGo is soooooooo much better than working with C/C++ or Rust as an example. Places like that where you wouldn't usually find a transpiled language (other than maybe Python with MicroPython).
Also, check out nanoFramework for a .NET runtime that can run on MCUs like the ESP32 [1]
I wouldn't use it for an MVC application yet because a lot of features won't work but there are plenty of other areas that are using it now and one of the biggest examples is Avalonia apps compiling to native.
C# is more expressive and .NET comes with batteries included. Go is more explicit and more verbose.
You can pick up Go faster and is easier to reason about Go code when you first encounter a new project but C# feels like it enables you to develop faster and be more productive.
For web both are excellent and performant, even if they have different philosophy.
What I like about C# is that it becomes more functional and I can even mix F# in the projects if I want even more functional programming.
I worked with C# for a decade, I'll likely never work with it again if I can help it. Not because it's bad, it's better than it's ever been. But because I really dislike the way they include their batteries. It leads to long debugging and refactoring sessions when tired people have written what is not their best work on years worth of thursday afternoons. I think people who like implicit frameworks must have been good enough to work in places that had better quality than the places I've worked.
Currently my favourite way to build applications (desktop or mobile) is Kotlin and Compose.
I never used Dart, how would you compare it to Kotlin ?
One issue the demos reveal is, it doesn't _feel_ like the web. That is, I can't hit Ctrl+F to find text on a page. I can't select text with my cursor. I can't copy the address of a hyperlink. On my phone, I can't hard press on an image and share it to others. Screen readers can't handle it. I can't press a shortcut key to make everything larger.
These all may seem pedantic, but they contribute to the feeling "this is not the real web."
This is the same problem with Java applets in the late '90s, Flash and Silverlight in the early 2000s. They are islands of richness within a web page, but those islands are, well, opaque to browsers, search engines, and virtually all web tooling.
This hits into that concept of what exactly the "web" is. Is it just a media transport system? Or is it something more than that. Of course, we could cite Tim Berners-Lee here or Roy Fielding in this discussion.
But at minimum, I think a lot of us are tired of the app-lification of the web and somewhat wish we could have a bit of the old.
I think some part of UI design degraded with the web, where there used to be a clearer distinction between "user data" and "app chrome" areas than there is today.
I'd also like if we could get back to selections of more complex data types at some point and not just treat everything as text. UI toolkits have all kinds of lists and treeviews to model selectable entities, whereas in the browser, there just a single huge wall of text for everything.
You've never had to type error code/message instead of copying&pasting? Or use search to jump to a specific settings section?
Don't know if that helps you particularly, but it is great when it works and little-known.
All the more annoying when such years-old fundamentals are broken in all the new "supposedly better" frameworks
I do miss this on an almost daily basis and I have stopped paying for services that force me to use an app without offering a website.
The last instance of this was just a couple days ago when I could not copy a tracking number from an e-commerce app (to then paste it into the shipping company website) but at least this e-commerce company has a web UI so I could rely on that.
Oh and the other one that I miss almost daily is cmd-F / ctrl-F
For macOS is by screencap and selecting on preview, for phones in their respective “ai analysis views” usually long pressing the bottom.
I know it’s a silly flow when it could be selectable straight away, just pointing it out.
- The “magic ocr thingy” exists for things like taking a picture of the real world and grabbing text from it, or grabbing text from a video from something you saw recorded there. Think translating a foreign sign or whatever.
- interfaces have, for unrelated reasons, become more hostile to standard actions like copypaste.
As a result people end up having to ocr-scan interfaces with the tool.
Mobile users have completely outpaced laptop/desktop users, and mobile users don't think in terms of files and text, so to them copy & paste is less important. The mythical "average user" moves arbitrary text and data around using screenshots and screen recordings instead of text and files.
Yes, it's incredibly inefficient, but I think it's evolved that day because selecting text is a real pain on a small touch screen, and companies have been trying to abstract away any concept of a filesystem for a long time.
So you or I might care and be bothered that we can't copy & paste something from UI chrome or content in a "web app" but the average person won't care, they'll just take a screenshot.
They're referring more to things like "you can't copy the text labeling the brush width field in Photoshop" (but you CAN copy the text out of that editable field). It's a part of app design people are extremely lazy with today, as you note.
In any sensibly designed desktop package tracking app that number would've been selectable or copy-able text, like how an email subject is in a desktop email app. (Thunderbird, say.)
(Interestingly, ctrl-f to find is one that many apps/OSes have now borrowed back, with the ability to "find" items in menus through a Help menu -> Search action.)
I forgot what desktop application it was, but there was a time that I repeatedly needed to copy texts from a dialog, which didn't support text selection. It frustrated me so much, that I put together a script to do OCR on the dialog.
Supporting complex data types for copy & paste is good; but it is almost trivial to also support plain text copying as a fallback when it already supports copying of other mimetypes. The problem is that some UI has no support of copying in any format at all.
on macOS, anything that uses the OS text input box has emacs keybindings. Universal text editing bindings across the entire OS for all native apps. You lose that with electron, just like you lose a lot of the windows niceties the moment apps stop using win32 and start overriding with their own custom UI toolkits in the name of "branding."
It's part of the big reason computers started to be perceived as difficult to use, and it's not because of the various operating systems. It's because desktop apps stopped respecting the OS and the user, so instead of only needing to learn the operating system's conventions, which would apply to every app built for it, you now have to learn every individual app's quirks and conventions.
The web just continued to make it worse where now every app is it's own little special snowflake.
I never "read" a desktop application, whereas that is mostly what I use a browser for. And if I can't properly interact with text on a website, then I would likely reach for something else.
Information-oriented desktop apps still do this - any good email client, for instance, should make it trivial to copy a subject line or "to"/"from" address even if it's in the UI chrome.
Good heavens. I boggled at this.
It's not every single day, but probably at least once a week I am frustrated by this, and have been since the rise of PC GUIs -- so, coming up on 35 years now. It was often doable on DOS-era PCs, especially if you had a mouse, or a multitasking environment like DESQview, or best of all, both.
I know there are strongly held opinions about this, but I for one see no reason why the "application web" can't peacefully coexist, and interlink with, the document web. In my opinion it therefore makes sense to allow for different models for the application web, ones that do not revolve around a document.
On the other hand, if we're just bashing on javascript being the lingua franca of the web, that's a train I'll happily board!
then forget that.
We were all worried about something like Spotify killing off open RSS feeds for them, but there's a growing number of people who have no idea what a podcast is because people are using the term for YouTube channels with full video and no RSS feed (video or audio) to match it. Sometimes language drift is good, but not when it's done on purpose to get rid of a free and open technology in favor of silos.
"Wherever you get your podcasts" only works as long as it's built on top of an open method of syndication.
W3C already offers guides for accessibility and canvas. But no one who opts for canvas turns around and remembers to do their landmarks.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Not completely true. Flutter has been adding some accessibility for web canvas target. [1]
I think Avalonia is in in the make it work phase. Accessibility will probably be added in the make it right phase.
[1] https://docs.flutter.dev/ui/accessibility/web-accessibility
Accessibility Object Model:
https://wicg.github.io/aom/spec/
It's very slowly coming together, but it won't be rone for many years yet. Especially since what you want is Phase 3.
I can't use your app, I'll use an LLM to read it!
I want every app and every web page to be 100% navigable if I do not have a pointing device attached to my computer.
And I want this enforced by law, by large rich countries. Accessibility to people with disabilities would be a good way: if your product or service is not accessible to people who can't see, can't use a mouse, or can't use their hands at all, then you can't sell it.
I was intrigued before I read this. This stuff is a non-starter for me.
WASM is just one of the platforms that Avalonia supports and so, if you run MAUI on Avalonia, you can run it on WASM.
If you do that though, it is going to be like rendering any other desktop GUI toolkit in WASM. It is not a web app. I mean, it is cool you can do it and MAUI in WASM is better than no web capability at all I guess. But you would never set out to create a web app in MAUI.
MAUI on Avalonia on WASM is really a modern replacement for Silverlight. And it will likely be about as popular.
The really cool thing is being able to target the Linux desktop finally. A lot of people will love that.
And, while MAUI was meant to use native controls on each platform, many people may prefer the Avalonia approach of having your app render the same everywhere.
I havent been in that space for a couple years now so maybe they have gotten better, but I doubt that. I appreciate the heroic efforts of the MAUI team, but I think its just the unfortunate reality.
We're betting on this over at https://github.com/DioxusLabs/dioxus where we're building a cross-platform UI solution that enables you to do this by having a web-centric API (we are developing our own custom HTML/CSS renderer for native platforms).
I get the value in this and realize it's not for your polished -$500 ARPU consumer social apps, but man this is weird.
(Also if anyone who worked on it is here, it's crashing for me on OSX 26, Chrome 142.0.7444.135, if I run an animation and hit back as the animation finishes)
That's because MAUI is intended for mobile and desktop apps.
If you want to use .NET for front-end web SPA, you can use Blazor which will behave exactly like you asked.
1000% - as a dotnet developer with 20 years under my belt, I currently don't see the reasoning behind this. With modern browsers, CSS/JS/HTML does SO much, you just don't have XAML. I like XAML (conceptually), but there is JSX for similar functionality, and it is at least compiled into real HTML, not just a applet.
I felt the same with silverlight as well. Why do we keep trying to reinvent Flash? We already have a far superior C# Flash in Unity compiled for Web (kind of a joke, but also not).
We got all the plugins back.
Also C# and .net overall are so damn good.
Anything to abolish the js and constant hacks upon hacks
Uno can render to canvas or the DOM in C#: https://platform.uno/
Blazor renders to the DOM: https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...
If it's better than what MAUI provides and you can support it for years, I'm sure that could take over and many people would use it instead. But... will you and why?
QT Framework is still one of the best for cross-platform desktop applications when speed is key.
(Which is ok for some situations, but not for wide deployment like .net provides)
1) In today's American political climate I think it's appropriate to express appreciation for immigrants to like Miguel de Icaza who dragged Microsoft kicking and screaming into cross platform .NET and is the godfather of .NET Maui
2) As someone who came up developing desktop apps for Windows and Mac, I never liked developing web applications. There was so much lacking, but now developing web apps is becoming like developing desktop apps. Now you get/put your data from HTTP calls instead of file system and database calls or with Blazor and SignalR you don't even have to think about those. This may seem obvious to younger programmers today, but it would have seemed like magic back in 2004 when Dymanic HTML and Ajax (both Microsoft) were being invented.
3) I'm grateful Microsoft has changed their old ways to be a forward thinking company. They still have problems that any GIANT, Inc. organization has, but let's not forget how far they've come.
Interesting, I wonder how good Impeller is and if it's actually better than the new Graphite backend of Skia.
the big difference is this
Predictable performance: Impeller compiles all shaders and reflection offline at build time. It builds all pipeline state objects upfront. The engine controls caching and caches explicitly.
Flutter’s Impeller renderer outperformed Skia. Impeller eliminates runtime shader compilation stalls, delivering lower frame times and more stable performance. For animation-heavy, graphics-rich apps, enabling Impeller significantly reduces jank and provides a smoother user experience.
[2] https://medium.com/@raiden.lpf666/skia-vs-impeller-a-perform...
> Using .NET MAUI, you can develop apps that can run on Android, iOS, macOS, and Windows from a single shared code-base.
This new development adds Linux and Browser to that list.
I recently tried out .NET MAUI to see how easy it was to build a hello world app. It was quite messy getting it setup on Mac but eventually I got a simple hello world app working. Nice to use XAML again after all these years. I always liked it.
I can't help but think of Joel Spolsky's Things You Should Never Do (5) - the transition from Xamarin to .NET MAUI feels like a very similar mistake to Netscape. All of the battle tested Xamarin code, documentation, community examples, packages, etc. is now dead and has to be converted over to .NET MAUI.
On top of that, XAML just doesn't do it for me - having to deal with code-behind, MVVM view models, custom converters, and the actual XAML files themselves is insane for what is usually just a a single file in JS. The fact that you need to write a "InvertedBoolConverter" (4) just to flip a boolean is the most Microsoft thing ever. MAUI feels like it's designed just to keep a large development team busy. I'm not joking, we have a 42 line file that's only purpose is to flip booleans for XAML views.
We're a C# shop so it was nice to share our common C# with our desktop application, but I don't think it was worth it in the end. Sure JS has its problems, but I'll take those problems any day over MAUI.
I hope Avalonia can fix .NET MAUI - it'd be a massive kudos to them if they can smooth it over, but I can't say I'd willingly rely on this project long term.
1 - https://github.com/dotnet/maui/pull/15612 2 - https://github.com/dotnet/maui/issues/8191 3 - https://github.com/dotnet/maui/pull/15655 4 - https://learn.microsoft.com/en-us/dotnet/communitytoolkit/ma... 5 - https://www.joelonsoftware.com/2000/04/06/things-you-should-... https://github.com/dotnet/maui/pull/16965
[1]: https://docs.avaloniaui.net/docs/reference/built-in-data-bin...
Why build a product on MAUI when Microsoft aren't too sure about it.
I think it’s better on the server side with ASP.NET.
As far as I have heard MAUI is pretty buggy and has lost momentum. It will probably go on the long list of basically abandoned .NET UI frameworks
Unfortunately Microsoft likes to jump into bandwagons and many engineers at the company seem to like to reinvent stuff rather than adopt. WPF, WinUI2 and WinUI3 all share the same Xaml based structure. So they could have adopted WPF.
It is not that Microsoft doesn't develop advanced UIs with their frameworks. WPF is still well-used by Windows and other Microsoft utilities like Windows Terminal. They are just stupidly abandoning their built up bases for silly industry fads.
They jumped into tablet / touchscreen / hybrid-mobile-desktop bandwagon in late-2010s and tried to force WinUI as an UWP-only feature. It resulted in low adoption. They didn't adopt WPF to have same theming.
When WinUI2 failed, they tried to make modern C++ a reality and tried to remove UWP restrictions which is a good decision. However they diverted quite a bit resources into AI slop generation now and WinUI3 just languishes.
Same for MAUI. They tried to get into multi-platform, multi-device framework as a way to generate leads into Microsoft ecosystem.
They try to use various frameworks and UI stuff to get people hooked into the ecosystem and find ways to upgrade them into Azure and M365 customers. It is meaningless and tiring. All of those could be only WPF.
It is like Google and its many Bazel-like build systems (but not full Bazel) for each of Chrome, Fuschia and Android.
Not exactly the word I'd use, since it really hasn't changed since VB4, but it's definitely reliable and stable.
Qt also seems to be a good option, though there are licensing considerations for commercial applications.
I’m excited for various upcoming Rust options as well, but right now Electron is the battle tested option.
I am curious though about Avalonia. I’ve heard good things, but it’s definitely a smaller player compared to Electron. I’d most likely choose it over Microsoft’s first party frameworks.
It's also the option which gives your users by far the worst experience. Not worth it at all, imo.
Plenty of category leading applications like Discord, VSCode, Slack, Figma, etc. use it quite successfully.
And most of the world is like that, very few of us (speaking globally) have $2k to drop on a new supercomputer every few years to run our chat applications.
Are there QT or GTK competitors crushing them?
I always hear how terrible electron apps are, but the companies picking electron seem to get traction QT or other apps don't and seem to have a good cross platform story as well.
Companies aren't picking Electron due to inherent shortcomings in other platforms, they're picking it because it's easier (and cheaper) to find JavaScript devs who can get up to speed with it quickly.
Your comment applies to Teams and I’m sure other electron apps. But the sweeping generalization that electron apps have terrible user experiences is pretty obviously incorrect.
One that comes to mind that I use daily and noticed only recently that it was implemented in Qt is the telegram desktop app.
I think Qt really is 'just' missing more language bindings, and a better hot reload story for more people to use it. Lots of devs (specially Free Software devs) would prefer to use native toolkits, if the prototyping experience was similar to how Vite is for web frontend stuff, I think Qt would be used a lot more.
> Qt also seems to be a good option, though there are licensing considerations for commercial applications.
you need to respect the LGPL with Qt. You also need to with Electron which uses Chromium which is LGPL.
To be fair, there is no practical way to write native desktop applications using stylistically consistent UI elements AND have it be portable AND in a language that you enjoy using.
As far as I can tell, Windows 11 doesn't even have a toolkit with platform UI elements.
GTK on Gnome is pretty okay and GTK-rs is not dissimilar to React. Who know what MacOS uses but something something Swift XCode.
But I agree, just use web technologies. Write once, ship everywhere (and hum loudly when people complain about poor performance - joking, it's the vendors' fault we have to use web technologies).
https://avaloniaui.net/blog/avalonia-partners-with-google-s-...
[0] https://mauikit.org/ [1] https://github.com/dotnet/maui/issues/35
108 more comments available on Hacker News
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.