This is interesting for sure. Kudos for bringing this capability to the web!
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.
That's not pedantic at all! Indeed, without these capabilities, it is by some definition not the real web.
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.
It's also an interesting question, why, in traditional rich desktop applications, I can't say I have ever missed the ability to select and copy text from the UI chrome - whereas on the web I'd definitly miss it and in badly designed mobile apps, I often do.
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.
> why, in traditional rich desktop applications, I can't say I have ever missed the ability to select and copy text from the UI
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
This is why technology is becoming garbage. In 2025 instead of copy paste, we fire up a gpu in a datacenter. it feels like "software engineering" is just becoming a BS contest for "how much AI can we shoehorn into everything"
Not fully disagreeing, but this lack of copypaste is not an intended ai feature.
- 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.
Some of it is because how people interact with and use tech has changed.
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.
"E commerce apps" are very much not the sort of traditional desktop application they were referring to. Note that they add "in badly designed mobile apps, I often do."
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 can't say I have ever missed the ability to select and copy text from 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.
> in traditional rich desktop applications, I can't say I have ever missed the ability to select and copy text from the UI chrome
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.
If it was a standard Windows dialog box by any chance, you could just have pressed Ctrl+C with the dialog in focus to copy the message. It's one of these subtle things that go almost completely overlooked.
There's a lot of nice little things like that in desktop OSes that we completely lose with everyone shifting to using electron, and I'm increasingly frustrated by it as time goes on.
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.
Thanks, doesn't help me, but you're right, a good tip to know. Though I'd still prefer a similar option to start selection directly in the UI instead of finishing the job in a text editor, this would also help highlight text in a screenshot without having to do image post-processing! I'd even accept some arcane finger-breaking ctrl-alt-win-x-y-z (which I could rebind) for the privilege
All the more annoying when such years-old fundamentals are broken in all the new "supposedly better" frameworks
While I do occasionally miss it there as well, I think the main difference is that I very rarely use desktop applications for information gathering.
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.
Back in ye olden days desktop applications for information gathering like Encarta let you select and copy text because they were thoughtfully designed and knew that "information you were gathering" should be different than "application chrome" - that's the distinction being made here.
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.
I've had the same thoughts as I watch YouTube slowly but steadily subsume "podcast."
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.
IMHO there's no gatekeeper of what the "real" web is or should be. It grew organically - regular people building things they liked or needed. It's certainly more of a life necessity than it used to be, but that happened organically too.
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!
Not using the standard web stuff usually means it's also an accessibility nightmare, tried using a screen reader on the demo and it doesn't work at all unfortunately
I wonder if at any point browsers will offer a low level accessibility API for you to manually describe components. I’ve worked in the web for years and I’m a big believer but it’s also indisputable that Canvas offers more performant UI rendering than HTML when done correctly. I don’t think it should ever be used for web “documents” but web apps already bastardize HTML and CSS to achieve their aims anyway. Accessibility remains the missing component.
It's HTML imagemaps from the 90s, when we could not style buttons and navbars where GIFs with links in the right places. Browsers still have the code to render them.
OTH, we are still failing to provide a bare minimum for accessibility. Heck, we even needed a law (in the EU, that than needed to be translated to national law), so that companies providing crucial end user services would care about accessibility.
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'm not aware of any screen reader that works by continuously feeding screenshots of user interfaces into a remote expensive image LLM, which is an absolutely insane and impractical idea for many reasons, but I used standard TalkBack on Android
MAUI was never intended for the web. This is not what Microsoft wants you to use it for.
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.
Blazor+MAUI has absolutely been a focus of development from the start. What Im seeing with this is that MAUI is somewhat throwing in the towel and hoping to offload to avalonia to take the torch of development. I'm sad, because I was pretty in the weeds with MAUI at the start, as I was building a greenfield app at the time. It had a ton of potential to be a reimagining of Xamarin and how it fit into the broader .net ecosystem but they just shot themselves in the foot (both MAUI team and the broader MS dev efforts).
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.
I think it's the same problem that flutter web has, and probably any other canvas/wasm based backend? Those features still need to be implemented, while still missing out on accessibility?
>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.
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).
Yeah. I think you need to render to actual DOM nodes when targeting the web if you want a first class experience.
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)
In the .NET ecosystem, I have noticed people to shame .NET MAUI because Microsoft themselves don't use this framework - Microsoft Team is built on Electron and not MAUI.
Why build a product on MAUI when Microsoft aren't too sure about it.
The answer to that is well known: Windows division builds WinUI/Win32 as their native C++/COM API, Office division went to React on their path to the web and the dev division fills gaps (WPF) and provides tools for external and internal devs (Maui for cross platform uis).
It is history not the lack of will. At one point the windows division was in shambles (remember vista) and WPF pops up. At another point, the windows and dev division have no answers to the office group (because you know who uses non win tech) so they went react. And then external devs screamed: where is the .net cross platform story so Microsoft acquired xamarin and later form Maui out of it.
It is history not lack of trust. But the outcome is the same: lackluster support for all UI toolkits.
Well summarized, and just as shocking today as it was every minute while it developed.
Someone needs to remind those cats that they own the platform. Being able to sanely develop apps for and on that platform should be possible, and UI kinda-sorta matters for that. At a certain point with the MFC they had it dialled in, while pioneering asynchronous browser tech, with many best in class tools. Decades later with a cross-platform cloud-centric stack they have a shrug emoji as big and wide as the eyes can see, and no sense this basic question of development will ever get improved.
Ballmer chanting ‘developers, developers, developers …’ springs to mind.
Ballmer was not my favourite person to run MS, but that was a pretty good time to be a Windows developer if you bought in. Early Nadella days too. Now? It's too easy to find no MS answers for almost everything, even triple-A gaming is not the windows anchor it's been since they ran that doom demo
> but that was a pretty good time to be a Windows developer if you bought in
I did, it was great. Very apple-esque in a way. As long as you stayed in Microsoft's garden, you had a good time. Microsoft had, at the time, one of if not the most productive stack to build GUI desktop line of business apps. If your whole org was Microsoft from top to bottom, even better. AD auth in your desktop app in a couple of lines.
It was an expensive stack for sure, but I'd argue there's still nothing that has come close to it if you want to build an enterprise desktop app.
As I understand it, Sinofsky is largely responsible for this mentality in the various places he worked across Microsoft: he instilled a distrust for anything originating out of other teams.
These days, I think Microsoft's web-based desktop apps mostly use WebView2 directly instead of Electron, so they don't have to bundle a browser. I think for Teams it happened at the same time that they moved from Angular to React.
The point about them not using MAUI still stands though. From what I understand, the .NET world has either adopted different abstractions like Avalonia, or stuck with tried and tested solutions like WinForms with proprietary controls. After all, they've seen this before with WPF which was never fully adopted by MS either, or with the debacle around Metro/WinRT. You're never quite sure what Microsoft wants you to use or will support in the long term. They also make Blazor, which is a different (and likely more accessible) way to build web apps with .NET.
Since we're on the subject of companies not dogfooding their shiny tech, is Google really using Flutter for their own apps? I feel like the evolution of the Android ecosystem towards Kotlin and Jetpack Compose implies otherwise.
Ive been building these apps (cross platform web based ui, C# backend) for years, and yes its finally good to see MS catch up and validate the architecture ive pushed since Xamarin. I wrote once wrote an electron version of this archand thought wtf are people doing? Things can be so much easier when you use a platform that knows how to multi-thread. At stages i had to build adapters/upstream patches for Chromeiunium directly onto Mac and Linux, and its was a major pain having to debug C calls.
Ive been using the same framework now for 10+yrs on apps in the stores, i wrote a small layer infront of the webviews and can swap out webkit, chrome, edge on demand. You really dont need much, just a constand way to boostrap logic and UI. 90% of code is shared across all platforms, there are def differences in WebView engines that you sometimes come across but those parts just get swapped out with browser specific JS. Ive found bugs and worked with browser teams at all vendors doing this and to see how simple this is with Dotnet these days compared to when i started is refreshing. Its easily the most stable cross-platform framework around, if you are stuck using something like flutter i pitty you, its just eletron with another skin. I can swap out and integrate directly with OS libs when i need to do stuff that the dotnet team hasnt gotten around to yet without re-writing. This has mean i really havnt used MAUI at all, but if i need to or could take advantage of it i can mix it on an Ui element by element basis. I prefer webUIs though, i have the chose to handle anything with either JS, WASM, or a combination. I can use traditional JS frameworks or traditional Native UI frameworks.
If i had started this process later, avalonia seemed to have the closest thing i required. It was just a bit a more complex /based on WinUI (which i dont really enjoy) but it supported all platforms and gave lower level api access. MS were smart, that canabalanised all these community effort and brought them into the fold. Every dotnet webview impl was a successfull community driven project before. They didnt write anything themselves from scratch.
> Microsoft Team is built on Electron and not MAUI
Microsoft Teams was released in March 2017. .NET MAUI was released in May 2022. In 2021, Microsoft replaced Angular with React and moved away from Electron to WebView2 (using the OS' built-in renderer rather than a bundled Chromium). So even the rewrite was a year before MAUI (and they probably started the rewrite before 2021). Plus, part of the point of using React there was that they could basically replace Angular bit by bit.
Microsoft Teams is just older than MAUI. It's like asking why Hadoop is written in Java and not Go or Rust or why Kafka is written in Scala and not Kotlin. Kafka was open sourced in January 2011 and Kotlin came out in July 2011. Kotlin wasn't an option given that they were developing it years before the language was released.
That's not to say that Microsoft's attitude toward MAUI doesn't leave concerns. There was some news a while back about a bunch of layoffs around MAUI. It's always concerning when there doesn't appear to be any dog-fooding going on - is this just some junk they're throwing at us that they don't want to use? I think some hesitation also comes from the Blazor side where it's looking like Microsoft doesn't really see Blazor as a React competitor so much as a way for internal company apps to be made quickly - in contrast to the Google IO presentations on WASM support for Dart/Flutter where they were emphasizing better-than-JS performance.
That said, Microsoft hasn't really released a lot of new (green field) stuff over the past 2-3 years. What product should they have made in MAUI, but didn't? You can't say Teams because that was a giant product way before MAUI even existed. Most of what Microsoft is doing is work on existing products - things they released before 2023/2024 and were in development before MAUI existed. Flutter had a 5 year head start on MAUI.
But there certainly is a feeling that Microsoft doesn't feel committed to it or at least not enough to put its weight behind it.
Never build a frontend on a .NET technology. Period. They always end up unsupported in the end. Just use standard web technologies and thank yourself later. I've been a .NET dev for a decade now and that's what I've learnt.
Blazor is pretty great. It is mature at this point and MS is using it internally more and more. Trying to go back to something like React makes me shudder. It's not perfect, but it's better than many alternatives.
I agree. For Blazor there is hope. It is standard based (web assembly, HTML, css) and it feels very intuitive particularly when compared to other spa frameworks like react. Also you can reuse all your html, css and design systems you have. Which is huge because like that it hooks up with the whole web development stack.
Tauri is pretty awesome. Rust backend, WebView front end. Nothing uses native desktop elements of course.
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).
In my experience with Tauri, it's pretty good on Windows, but not so much on other platforms, especially Linux. The decision to target different browser engines on each operating system means you still have to deal with a bunch of different OS-specific bugs.
For Windows you're dealing with Edge (so Chromium), on macOS you have Safari, and on Linux you have WebKitGTK. WebKitGTK has honestly abysmal performance, and you're missing a lot of modern standards.
The Tauri devs are looking at bundling a Chromium browser with it to deal with that, but that's still some time off, and leads to the same issue Electron has, where you have large bloated applications.
I don't know much about it but it seems like a weird combination. If you want high performance and low memory usage, you don't want HTML, if you want fast code writing, you don't want Rust.
I don't believe you generally end up writing a lot of Rust with something like Tauri. It is mostly web dev. While it is true that browser based UIs are slower than native, it isn't clear that .NET based UIs would be any faster while being very niche.
I could see a case where the core logic needs to be performant, but the UI does not. The front end could be some menus, displaying (not a giant amount of) data, and a progress bar, while the back end does heavy computing.
And furthermore, if you want fast code writing, you write in the language you already know. For some people, that is Rust.
- HTML is the main way of designing interfaces (whether we like it or not)
- Rust is the main language promoted by intelligence agencies with multi-billion dollar budgets because it is laced with their backdoors (whether we like it or not)
As wrong as it feels to have to use Electron for a desktop app, it really is the safest approach for most applications.
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.
Does their market share back up your take of them as horrible apps?
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.
Users will happily deal with a suboptimal experience as long as there are other things attracting them to the product. That's why Microsoft can do whatever it wants with Windows without worrying their users will run off somewhere else. So if you care more about people than businesses, maybe it shouldn't be an excuse to pick "better dev experience" over the user's.
They said horrible user experience apps, not horrible apps. You can still deliver an app with a horrible user experience and build a profitable business. Ever done an expense report?
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.
Discord, VS Code, and Figma are all apps that individuals choose and are well liked despite many alternatives. Slack too I think, though I don’t have experience with it.
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.
Oh yes, the great old "works for me". On a yesterday's supercomputer, I presume? I live in a "developing" (have doubts it's really developing) country, most people are running laptops with no more than 8 GiB of RAM (sometimes it's 4 or less), and all this Electron nonsense is running like molasses, especially if you're trying to use a computer like a proper computer and do multitasking.
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.
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.
Thanks for sharing. I hope that initiative goes well. And again, integration with whatever solution the language has for hot reloading is a must these days for UI development.
Same for me. I used to do desktop dev with MFC and WPF but these days you would be suicidal to build any app that needs to last for a few years on .NET. If totally needed, WPF is still the best bet. Otherwise I am pushing everything I can to the web.
You are right that WinForms and MVC have been around forever. However, Microsoft has continuously told devs that they are the past. So, you would be forgiven for expecting them to go away.
WinUI is the current official desktop paradigm and it is basically UWP from an API point of view. So the idea that UWP went away is not 100% accurate either.
Microsoft does not really abandon their UI tech like people say they do. But look how many different frameworks they have.
All of the above is Windows desktop only. There are a completely different set of UI technologies for the web.
UNO Platform (Open Source) allows you to use the WinUI API to target almost anything.
.NET MAUI is the official "cross platform" UI tech from Microsoft. It is what you use to target iOS and Android. As a bonus, you can target macOS and Windows too. On Windows, it uses WinUI. You will notice that the Linux desktop is missing from that list.
Here comes Avalonia to build MAUI on top of the Avalonia framework. This adds Linux and WASM to the list of platforms that MAUI will run on. Adding Linux is awesome. A lot of people have wanted that and it really completes the MAUI cross-platform story.
Adding WASM is neat but MAUI was never meant to target the web. If you use it for that, it is literally just the modern version of Silverlight. But Microsoft did not design it for that at all. It is just a back-end that Avalonia supports.
MVC is a design pattern, ASP.NET MVC is a framework that used MVC as its go to pattern. But MVC is not in any way only ASP.NET MVC. There are plenty of other UI frameworks that use MVC and the Wikipedia article lists a lot of them for example: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93con...
No kidding - kind of wild that winforms is still kind of a gold standard experience today! I actually liked VB Forms - lots of easy rapid application development was possible.
Delphi was the best RAD tool though. It was native code, not a weird interpreted or jitted app. It could also build to a single exe file. VB struggled with an unwieldy engine for most of its life.
I like WPF and I code with it regularly, but the drag and drop UI builder was the worst aspect of WPF and generated terrible Xaml that was almost impossible to maintain.
I was going to suggest the same, just use WinForms. It's basically feature complete, and it's going to be the last UI framework Microsoft is going to yank out from beneath you.
Generally speaking, I wouldn’t take what Microsoft uses as guidance nowadays, given a lot of the software they produce. (This is not an endorsement of MAUI.)
That has been a problem since forever. Microsoft themselves rarely used the tools they gave to developers. SourceSafe, MFC, WPF and the .NET frameworks that followed were only for 3rd party devs. And when they used these tools, the software usually got worse. One example was Visual Studio. 2008 was really nice with great customization and good performance. Then they wrote 2010 with MFC and it was slow and lost tons of features.
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
You are mixing your UI frameworks and versions. VS 2010 is written in WPF. WPF is / was Windows Vista's and 7's UX. Old Control Panel in Win 10/11 still is WPF. All the wizards like ClearType wizard is WPF. MFC is much older (1992).
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.
MAUI was horrible when I tried using it about a year ago, tons of bugs, pretty iffy comms/support from the MAUI team as to timelines when things might get fixed, etc.
Eventually dumped it and moved to Kotlin Compose/Multiplatform, which is just so much better at achieving a similar goal (though, obviously, without being part of the .NET ecosystem).
microsofts own stuff never seems to be what gets momentum. there's a strong aftermarket for better ways like back in the borland era bcb and delphi, the more things change the more they stay the same!
> 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.
> We are collaborating with the Flutter team at Google to bring Impeller, their GPU first renderer, to .NET. That work is already in progress and as it lands, the MAUI backend will inherit those gains.
Interesting, I wonder how good Impeller is and if it's actually better than the new Graphite backend of Skia.
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.
or as described here [2]
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.
My kingdom for a UI toolkit that can be used to make real CAD programs, and not yet-more things that just look like webviews and could just be a webpage.
This 100%. I hate the trend of UX/UI that got unleashed upon us in the last decade of the web. Everything is scaled up for touch interactions and has to have fancy animation and very "comfortable" spacing around elements.
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 make CAD programs with any toolkit as long as you have a GPU surface to render your actual CAD output to. You can do anything with this toolkit from weather apps to video editors, map analysis, and PDF editors.
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
You could look at Godot. Their own editor is made with Godot’s own UI toolkit and in a CAD application you probably don’t care about some of the downsides this would entail for a CRUD app (accessibility, perhaps text layout etc.).
Yes, that's my litmus test for GUI toolkits - is it suitable to develop Photoshop-like software? Or is it only good for yet another weather or todo apps?
I'm currently in the process of creating a piece of development software and needed a cross-platform GUI environment to do it with.
I first tried Maui because its seemingly so highly rated and recommended. It turned out to be a complete nightmare. Even just installing it didn't just work, I had to spend 2-3 hours just to get that going and then when trying some basic things for my UI it turned out to just not be supported.
The next on the list was AvaloniaUI and wow, it was the complete opposite experience. Installation was a breeze and with only a marginal bit of googling I managed to do all kinds of things such as making a top-most only borderless transparent window etc.
The interface in Visual Studio could be a bit better overall, but compared to Maui its light-years ahead.
Finally, finally, I can use something apart from Kotlin Multiplatform and Electron to build slow alien-looking applications with annoying animations and phone-styled UX for Linux (and, let me guess, there is no native Wayland backend). Of course the set of widgets is comprehensive - there are button and checkboxes, what else might we need.
I'm wondering why all the demos of modern UI toolkits look and feel worse than Delphi 1 demos from prehistoric age.
You can (and could have for a while now) just use Avalonia natively. It supports Windows/Mac/Linux/WASM natively already. I think this work is primarily for those who already have MAUI apps and want to target Linux/WASM from an existing codebase.
I go to "Launch MAUI in your browser" [0] in section "Try It Right Now". I click on "Word puzzle - A word puzzle game", third of the demo apps. I click on the "Randomize" button. Tiles start shifting around. I click on the left arrow at the top to go back to the main menu. The whole thing becomes locked with the word puzzle on the background and the main menu on top of it. Nothing is clickable any more.
Yeah the shuffling takes ages. Once it's finished you can go back. Also the movement of the tiles feels very strange with the mouse. The Click-Drag sometimes works and sometimes doesn't. No visual feedback is given on click. The tiles don't move but teleport, which is strange for a click-drag interaction. A simple click would have been better, or a move animation. Someone else noticed it, too https://news.ycombinator.com/item?id=45893986#45897805
It seems like alot of people in this thread dont undestand the dotnet stack. MAUI, Native UIs, and WASM are all interchangable. Your cross platform app could literly be built out of everyone of of these components at once. MAUI is not required for use-cases generally when you have a webUI, its really targetting at the simple UI, write-once, run anywhere crowd. Once you outgrow it, you can move to native integrations using dotnet linux/mac/windows. Or you can just integrate with webviews, and have C# backend's or WASM backends. The combination is limitless.
Xamarin turned into dotnet, Xamarin.forms turned into turned into Maui. Name another large tech company that has embraced community projects like this and pushed provided enterprise support for community driven stuff over the same period.
I was writing cross-platform apps before Flutter, angular, or whatever other language you choose for 11yrs now. Find another framework thats done this before the scare tactics of "MS will abandon this" rhetroic. dotnet is the premier cross-platform enterprise ready framework full stop. No other framwork has the backwards compatiblty while maintaining paritity with the latest OS APIs. No other framework can serve millions of pages per/sec while supporting pixel perfect UIs and code-reuse. They have invested so much money in building automation that means as soon as the OS releases an API, your getting access to it. In real world terms, this is what counts if you want to build cross-platform stuff that your clients cant tell isn't native.
I run the same code from 2014, today, in apps in all the stores. Over the years all i have had to change is various namespaces to take advantage of the latest enhancements. Code that ran on dotnet4, silverlight, xamarin, still runs today on dotnet10. I share 90% of code across all platforms yet clients cant tell they are not native apps. Thats what i call return on investment.
I agree that, despite all the complaining, code re-use and longevity on .NET is second to none.
Where there is intense confusion in these comments is in thinking that MAUI is a web application framework. MAUI is "cross-platform" as you say but really mobile first with desktop brought along for the ride. It is in no-way intended to be a web application tech.
Avalonia has created an Avalonia back-end for MAUI which means running MAUI apps wherever Avalonia is supported, and that includes WASM. So now you can run MAUI apps in a browser. You can but that does not make MAUI web tech.
I can run Windows 95 in a browser. That does not make Win32 a web API.
I wish it was a real "systems" language as well, i.e. not single-threaded/javascript-mindset one. That's why I hope someday we will have a nice cross-platform framework for Swift.
I whish that too, but I'm not holding my breath since Google needs Dart-to-JavaScript compiler, which will continue limiting features Dart can implement. The only way this can change is, if they move to WASM and drop JavaScript target.
Go is frankly the polar opposite of C#. Go compiles to a native binary with no runtime dependencies and it relies on simple garbage collection and static linking. C# runs on the .NET runtime which is heavily managed, gives you JIT, reflection, dynamic code generation and so on. Go views concurrency as fire and forget, C# views it as compose and await. Go is extremely explicit while C# is extremely implicit.
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).
C# has AOT compilation which creates a single, native binary. This has gotten so much better with .NET 10 and since the introduction of source generators to deal with reflection issues.
Also, check out nanoFramework for a .NET runtime that can run on MCUs like the ESP32 [1]
Cool, I didn't know this. I see it's been a thing since .NET 8, but it also looks like something that is perhaps mostly meant for hobby projects? Or maybe I'm getting that wrong.
Definitely started that way for me. It was cool to see a console app written in C# be compiled straight to native and run. Since then, a lot of work has been done to make AOT viable for more workloads.
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.
.NET can be compiled to native binaries. .NET can be used for embedded development.
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.
Cool I didn't know about it's AOT, but it looks very... well hobbyist. Anyway, "Go is more explicit and more verbose" is a feature, but that's a matter of personal taste.
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.
The sliding puzzle is really finicky, have to try multiple times to slide stuff, the top left (back) arrow stopped working altogether until I refreshed the page, which of course takes you back to the original page... The time picker looks awful with the numbers not centrally aligned to the control (they look too high), and it's finnicky to use / same with the date picker.
Avalonia is also working towards using the new Flutter rendering backend Impeller which is being used to replace Skia, which is used by Chrome for rendering, turtles all the way down:
I wouldn't use it for consumer apps because it requires a Websocket connection to maintain state and probably doesn't scale very cheaply... but for business applications or personal tools it's actually kind of insane how much functionality you get out of the box (at least by the standards of statically typed languages).
.NET works amazingly on the web. This is just not the UI framework you would use.
There is ASP.NET of course and Razor Pages. We all use apps built with these every day without even realizing it. There are other great frameworks as well.
I do not even see Blazor as a real web technology but of course it is positioned that way.
MAUI is a "cross-platform" and frankly mobile first UI framework. It was never meant for the web.
You can make your own better system which supports GUI and provides a reasonable runtime that works on all current major platforms and provides development tools, years of ecosystem development, etc. etc.
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?
Anything would be better than another UI toolkit made by Microsoft. They will abandon it in the matter of a few years like they did about 10 times already.
I started moving to using GO and Fyne for cross-platform GUI tooling. GO 1.21 supports Windows 7 with Fyne. Ya still have to support Windows 7 for work. No more wasting time with managing a Windows installer.
QT Framework is still one of the best for cross-platform desktop applications when speed is key.
Like I said tooling. Means that the User is well defined where Accessibility is not an issue. The tooling I creating is for people that have to engage with physical equipment; from replacing parts to making sure a motor is working properly.
To clarify, it's using React Native XAML, where XAML is Microsoft tech for building UIs. So they are dogfooding but they have too many UI frameworks to choose from.
You wouldn’t use MAUI to build something for only one platform. You would just use whatever it’s an abstraction over for that platform which in the case of Windows is WinUI.
It's a nice idea, but the execution is taking the wrong path in my opinion. By rendering everything to a `<canvas>` they're sacrificing any hope of accessibility and compatibility with browser standards for UX.
I would have much preferred a React-Native-style approach, where they render to true HTML instead. Even then, WASM files are too heavy for quick loading times without good internet (and sometimes even with).
The projects I see that would most benefit from something like this are complex internal apps that need to be used in different places but aren't worth porting over/rewriting, but they would also suffer from terrible UX given the constraints of this design.
For all other projects, it makes for more sense to use React Native.
Accessibility is for all user experiences, not just websites. WCAG is still a good resource for native apps even where some specifics do not 100% apply.
If Qwasm is referring to Quake, it absolutely should have, for example, legible color contrast and be usable if you are colorblind.
What else do you build on the web with a UI framework if not a website? If you're making a distinction between websites and webapps, it's equally important for both to be accessible and work as expected with a browser.
VSCode is a webapp [1], that is most often used wrapped in a shell that lets it act as a desktop app.
Even if you do consider it separate from webapps, it should still work with tab navigation and screen readers, which rendering to `<canvas>` doesn't allow for (at least without some very hacky workarounds).
Flutter faces a similar problem; to render cross-platform, they use a custom layer not standard to the system, and then try to emulate all the behaviors of a native app, which often feels broken and unnatural and is wasted work because the engineers are just rewriting and reshipping everything the platform already offers—at the cost of accessibility and general user experience.
Open the demo... takes forever to load... open first app, calculator... looks awful... presses back (Chrome on Android)... back navigation is broken and it leaves the whole app returning to the previous website.
It's great to have .NET ecosystem expanding.
I am a .NET dev, and I still use web optimized for mobile as my mobile platform(where applicable). Tried MAUI and all the other stuff, just doesn't cut it for me. You can make an app using it, but I would rather not to. The best 'mobile platform' for me was blazor hybrid, but then again - if it's already blazor why not go full web...I guess it depends on the 'seriousness' of your mobile application. If I had to develop a complex mobile app, I might choose another language framework, cause MAUI uses XAML and MVVM stuff that is quite a big overhead IMO.
Building MAUI with Binding/Layout/Themes on top of another engine with Binding/Layout/Themes doesn't sound efficient.
Plus, it is my assumption/understanding that there's no way 3rd party controls will be able to run on Linux/Browser unless they're built directly against MAUI API without any Native our Skia dependencies, which is almost never the case from the libraries I've been using.
Would be interested to know about the a11y story on web and other platforms. Does it integrate with screen readers, accessible navigation tools, a11y apis, etc.
This is somewhere quite a few tools fall down. For example, for web: Rendering to canvas doesn't create the dom nodes required to hook into the tools, and creating the nodes appropriately can have a significant performance impact.
What about native a11y tools and tech.. there are some ios specific ones that you'd expect on an ios app for example.
I don't know if it has since improved, but .NET MAUI was really, really rough when I created a mobile app for my employer last year. I'm talking basic things - changing basic colors on the toolbar (1), putting non-text content inside a button (2), basic trigger behavior (3), to list a few. Not to mention that .NET UI has been years behind on hot-reload and developer tooling. Additionally, It was a fight to keep our app performant. The XAML compiler is a step in the right direction, but we had relatively simple views (in the dozens of components) absolutely tanking our FPS. I know there is probably some of my skill issue in there, but when I find basic things taking hours to optimize that I wouldn't even think about in React, I start to wonder about the framework. I spent a lot of time creating PRs on .NET MAUI but their team appears quite small and overloaded. I wish them the best - they're some talented folks, but I don't envy their job.
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.
Well, I guess Avalonia can solve 4 at least as you can negate a binding[1]. Good news for me as I recently started an Avalonia project, and thought you did still need an InvertedBoolConverter.
A toolkit announcing “Linux support” is pretty ambiguous. Does it mean Xorg support? Wayland support? Framebuffer support? The announcement provides no clue about this.
They are not announcing Linux support for Avalonia. It has long supported Linux.
What they are announcing is being able to run MAUI on Avalonia such that you can run your MAUI apps on any Avalonia supported target. This includes both Linux and WASM, neither of which is supported by MAUI directly.
Since it's using Avalonia, I'd say it's just X support at the moment. They've announced that they intend to support Wayland, but that was a couple months ago[1], so I doubt that's ready.
A while ago I was at an agency and we got a client that was a very popular weather app. Things like mapbox and some analytics libs (can't remember exactly, this was 2019) The project was a big redesign of the app. We looked into using Xamarin to see if we can at least write the core logic in C#. The issue we ran into is that there were many third party libraries we needed to import that weren't converted to Xamarin/C#. There was a way to try and have it automatically bind but never worked properly. In the end we just went pure native. Turns out Xamarin was a fun toy framework but Microsoft couldn't point us to anything serious and battle tested in production written in it.
I'm curious to see if .NET MAUI will surpass Xamarin and actually get serious adoption. They have to figure out the third party binding issue.
This is awesome… but:
On the Web, is Avalonia using Skia to render inside a Skia Canvas?
**insert inception meme here**
Joking aside: this points to MSFT moving away from the whole Mono/Maui investments and into Aspire or whatever they call it. Without MSFT backing this I am not sure if there is much more future left for MAUI (or dotnet on mobile in general).
I clicked a total of three times in the demo page before the tab froze and locked up.
MAUI is nice, and I'm glad it's getting decent Linux support now, but I would never use it in the browser.
Avalonia's big money ticket is taking old WPF projects, making minor changes to the XML to load their tools, and instantly making the projects work on macOS/Android/iOS/etc. (for an enterprise fee, of course). Great for forcing internal .NET applications built to run on Windows Vista into the modern world, but I don't think their web platform is a good idea for new projects because of the massive overhead you end up with.
This is absolutely horrible and I hope I never have to use it on the web - right click doesn't work, my plugins don't work, I can't even open DevTools and when I manage (before the app has loaded), it's just a <canvas> element in the page. I know a lot of people put work into this and something is probably better than nothing, but actually no, I think such solutions are disgusting.
If you're gonna claim cross platform, don't just stoop down to the lowest common denominator and write a bunch of pixels to the screen, use the damn system UI solutions, or in the case of web apps - HTML, CSS and JS/WASM. I already take an issue with Electron (Lazarus lcl did things right, in contrast) but realize that it yields a lot of utility, yet these canvas based approaches for web apps feel like a step too far.
Yet obviously nobody can admit that they can't do the heavy lifting needed to support multiple different target platforms for the same widgets in a way that respects the corresponding platforms, while also still wanting to ship something. In this case, I think nothing is better than something, if that something is so bad.
If it runs on Avalonia anyway why choose MAUI? If you have the option just use Avalonia.
MAUI is unfinished and its docs is awful.
Do you want to build an app using MAUI? Unless you build an app that barely deviates from the template, expect to desperately search through decade old Xamarin documentation and figure out the details through painful trial and error.
It is a way to get people choosing the "official" path (ie. choosing MAUI) to experience Avalonia. They are hoping you come for the MAUI and stay for the Avalonia and become an Avalonia developer.
As for, why choose the Avalonia version of MAUI, there are three reasons:
- Linux support (the big one I think)
- Drawn framework (same renderer on all platforms)
- WASM support (probably useful sometimes but not the real draw)
They are making a big deal of WASM here because it is easy to demo. We can all go into it and run it. But do we want to use it for our apps?
As for, why not Avalonia directly? To loop back to the beginning, it is because you do not yet know Avalonia and trust it. The Avalonia team is hoping this helps with that.
Thank you for explaining this. I didn't even realize this was an Avalonia project until you pointed it out. I like Avalonia (and love .NET in general), but I think the messaging on this needs a lot of work. Avalonia is creating unnecessary cognitive dissonance by emphasizing MAUI, which is a competing project after all.
This is what mystifies me about this announcement. Avalonia already works fine on Linux, allowing anyone to build a cross-platform .NET GUI application.
MAUI is supposed to be a wrapper around native widgets. The fact that they had to use Avalonia under the covers to get it to work on Linux seems to defeat the point. (Avalonia is a complete UI toolkit, like Qt or Flutter, that owns the entire stack from XAML to pixels.)
I've pretty much considered MAUI a non-starter without Linux desktop as a target and even with this, not sure I would consider it over just using Avalonia directly. Of course, it is nice to see this option getting flushed out for existing projects.
Does "Web" mean fully wasm (i.e. weird quasi-useless dialect that can't run a lot of code without being specifically aware of it's wasm/webiness) or some combination of that and a server?
This is a huge win for people using MAUI. The only thing I worry is some performance loss from using Avalonia backend instead of using directly the target platform.
Honestly, I feel that everything UI related has gone backwards to the stone age.
I wonder how hard would it be to go back to visual designers like we had with Delphi or VB6. There were flexible layout container components which helped a lot when adapting forms to varying screen resolutions.
Pathetic that MS doesn’t manage to do this themselves.
Even more pathetic that MS doesn’t actually use it for any of their products, so forgive me if I have very little faith in the future of MAUI with all its bugs.
tThis is another horrible, "lets render everything in canvas" framework so no select, no OS level context menu, no accessabiltiy, can't look up a word using your OSes dictionary, no IME support so no Japan/Korean/Chinese/Thai input, no find, no extensions, because there's no structure to look at, no translation extensions, in fact no translation period. Ugh!
Not in the industry I work in - AAA gamedev. Art folks typically would have two, or even three monitors - so good solutions for docking across them (and still working) are required.
A chrome browser by itself can't work that - it's great for many things, but not for Creative Tools.
MAUI is first and foremost a mobile UI framework. It was built for iOS and Android. The desktop is added on as a bonus so that you can target macOS and Windows as well.
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.
I would much rather see web apps become canvas rendered WASM versions of desktop apps than desktop apps become webview apps. Latter is what we have been seeing in the recent years unfortunately.
Canvas rendered cross-platform UI frameworks like Flutter & Avalonia targeting browsers (WASM), might shift the balance back in favor of desktop UI.
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.
This is interesting for sure. Kudos for bringing this capability to the web!
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.
That's not pedantic at all! Indeed, without these capabilities, it is by some definition not the real web.
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.
It's also an interesting question, why, in traditional rich desktop applications, I can't say I have ever missed the ability to select and copy text from the UI chrome - whereas on the web I'd definitly miss it and in badly designed mobile apps, I often do.
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.
> why, in traditional rich desktop applications, I can't say I have ever missed the ability to select and copy text from the UI
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
Most mobile experiences (and macOS desktop) let you select unselectable stuff with OCR.
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.
This is why technology is becoming garbage. In 2025 instead of copy paste, we fire up a gpu in a datacenter. it feels like "software engineering" is just becoming a BS contest for "how much AI can we shoehorn into everything"
Not fully disagreeing, but this lack of copypaste is not an intended ai feature.
- 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.
Some of it is because how people interact with and use tech has changed.
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.
I never tried that, thank you!
"E commerce apps" are very much not the sort of traditional desktop application they were referring to. Note that they add "in badly designed mobile apps, I often do."
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 can't say I have ever missed the ability to select and copy text from 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.
Same, and especially with error messages/dialogs.
> in traditional rich desktop applications, I can't say I have ever missed the ability to select and copy text from the UI chrome
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.
If it was a standard Windows dialog box by any chance, you could just have pressed Ctrl+C with the dialog in focus to copy the message. It's one of these subtle things that go almost completely overlooked.
There's a lot of nice little things like that in desktop OSes that we completely lose with everyone shifting to using electron, and I'm increasingly frustrated by it as time goes on.
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.
Not being able to copy text from UI interfaces is just normalization of deviancy. It should be the norm and it’s subpar when not possible imho
> traditional rich desktop applications, I can't say I have ever missed the ability to select and copy text from the UI chrome
You've never had to type error code/message instead of copying&pasting? Or use search to jump to a specific settings section?
On Windows, with common messages boxes, you can just do Ctrl+C for copy and you get the message box text in the clipboard.
Don't know if that helps you particularly, but it is great when it works and little-known.
Thanks, doesn't help me, but you're right, a good tip to know. Though I'd still prefer a similar option to start selection directly in the UI instead of finishing the job in a text editor, this would also help highlight text in a screenshot without having to do image post-processing! I'd even accept some arcane finger-breaking ctrl-alt-win-x-y-z (which I could rebind) for the privilege
All the more annoying when such years-old fundamentals are broken in all the new "supposedly better" frameworks
I’ve never done it twice, I can tell you that much!
While I do occasionally miss it there as well, I think the main difference is that I very rarely use desktop applications for information gathering.
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.
Back in ye olden days desktop applications for information gathering like Encarta let you select and copy text because they were thoughtfully designed and knew that "information you were gathering" should be different than "application chrome" - that's the distinction being made here.
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.
I've had the same thoughts as I watch YouTube slowly but steadily subsume "podcast."
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.
IMHO there's no gatekeeper of what the "real" web is or should be. It grew organically - regular people building things they liked or needed. It's certainly more of a life necessity than it used to be, but that happened organically too.
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!
If the “application web” can’t share the text to another app,
then forget that.
Not using the standard web stuff usually means it's also an accessibility nightmare, tried using a screen reader on the demo and it doesn't work at all unfortunately
I wonder if at any point browsers will offer a low level accessibility API for you to manually describe components. I’ve worked in the web for years and I’m a big believer but it’s also indisputable that Canvas offers more performant UI rendering than HTML when done correctly. I don’t think it should ever be used for web “documents” but web apps already bastardize HTML and CSS to achieve their aims anyway. Accessibility remains the missing component.
As far as standards is concerned, that API is ARIA [0].
W3C already offers guides for accessibility and canvas. But no one who opts for canvas turns around and remembers to do their landmarks.
> But no one who opts for canvas turns around and remembers to do their landmarks.
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
Then I’m showing my ignorance… how do you add ARIA landmarks to Canvas elements?
You would create transparent DOM elements in the right places with the right ARIA attributes and content, I suspect.
I guess that’s what I’d like to see a better API for, then. Mapping on click events for invisible elements feels like a hack.
It's HTML imagemaps from the 90s, when we could not style buttons and navbars where GIFs with links in the right places. Browsers still have the code to render them.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
https://caniuse.com/mdn-html_elements_map
OTH, we are still failing to provide a bare minimum for accessibility. Heck, we even needed a law (in the EU, that than needed to be translated to national law), so that companies providing crucial end user services would care about accessibility.
That's possible. But it is difficult to get right, and can have poor performance if you you have many such elements.
> I wonder if at any point browsers will offer a low level accessibility API for you to manually describe components
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'd just like the PgUp, PgDn, and arrow keys to reliably scroll a web page.
Oh my yes.
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.
What screen reader? Over the last few years AI's ability to understand images has improved a lot.
I'm not aware of any screen reader that works by continuously feeding screenshots of user interfaces into a remote expensive image LLM, which is an absolutely insane and impractical idea for many reasons, but I used standard TalkBack on Android
That’s not exactly fast for people who need these tools though.
I can't code, I'll use an LLM to write one!
I can't use your app, I'll use an LLM to read it!
Slow and expensive. You’re just proposing yet another “disability tax”.
MAUI was never intended for the web. This is not what Microsoft wants you to use it for.
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.
Blazor+MAUI has absolutely been a focus of development from the start. What Im seeing with this is that MAUI is somewhat throwing in the towel and hoping to offload to avalonia to take the torch of development. I'm sad, because I was pretty in the weeds with MAUI at the start, as I was building a greenfield app at the time. It had a ton of potential to be a reimagining of Xamarin and how it fit into the broader .net ecosystem but they just shot themselves in the foot (both MAUI team and the broader MS dev efforts).
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.
> 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.
I was intrigued before I read this. This stuff is a non-starter for me.
Can you ctrl-f in an iphone app? Or in vlc? It’s an app, not a document.
I think it's the same problem that flutter web has, and probably any other canvas/wasm based backend? Those features still need to be implemented, while still missing out on accessibility?
>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.
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.
If this can’t support web standards it’s a nonstarter for me.
Agree. The examples feel a bit like I'm using a specific window in remote desktop session.
> They are islands of richness within a web page.
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).
Yeah. I think you need to render to actual DOM nodes when targeting the web if you want a first class experience.
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).
Let's move the goalposts downfield. If you can't go into developer mode and mess with the DOM, and JS, it's not real web.
Unironically – yes.
By the way my comment was likewise already unironic.
Am I losing it or am I looking ClearType on OSX?!
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)
I can't hit my browser's back button.
Isn't Webassembly cool?
We got all the plugins back.
In the .NET ecosystem, I have noticed people to shame .NET MAUI because Microsoft themselves don't use this framework - Microsoft Team is built on Electron and not MAUI.
Why build a product on MAUI when Microsoft aren't too sure about it.
The answer to that is well known: Windows division builds WinUI/Win32 as their native C++/COM API, Office division went to React on their path to the web and the dev division fills gaps (WPF) and provides tools for external and internal devs (Maui for cross platform uis).
It is history not the lack of will. At one point the windows division was in shambles (remember vista) and WPF pops up. At another point, the windows and dev division have no answers to the office group (because you know who uses non win tech) so they went react. And then external devs screamed: where is the .net cross platform story so Microsoft acquired xamarin and later form Maui out of it.
It is history not lack of trust. But the outcome is the same: lackluster support for all UI toolkits.
Well summarized, and just as shocking today as it was every minute while it developed.
Someone needs to remind those cats that they own the platform. Being able to sanely develop apps for and on that platform should be possible, and UI kinda-sorta matters for that. At a certain point with the MFC they had it dialled in, while pioneering asynchronous browser tech, with many best in class tools. Decades later with a cross-platform cloud-centric stack they have a shrug emoji as big and wide as the eyes can see, and no sense this basic question of development will ever get improved.
Ballmer chanting ‘developers, developers, developers …’ springs to mind.
Ballmer was not my favourite person to run MS, but that was a pretty good time to be a Windows developer if you bought in. Early Nadella days too. Now? It's too easy to find no MS answers for almost everything, even triple-A gaming is not the windows anchor it's been since they ran that doom demo
> but that was a pretty good time to be a Windows developer if you bought in
I did, it was great. Very apple-esque in a way. As long as you stayed in Microsoft's garden, you had a good time. Microsoft had, at the time, one of if not the most productive stack to build GUI desktop line of business apps. If your whole org was Microsoft from top to bottom, even better. AD auth in your desktop app in a couple of lines.
It was an expensive stack for sure, but I'd argue there's still nothing that has come close to it if you want to build an enterprise desktop app.
I understood (can not confirm it though) that the new start menu in Windows 11 was built using React Native, so yet another ui framework in the mix.
This feels a lot like the Linux desktop ecosystem where many apps have a different look and feel (GTK, Qt and a bunch of others).
Except for the fact that microsoft is one company.
> Windows division builds WinUI/Win32 as their native C++/COM API
Windows for many years is just a pile of different browser engines stashed one atop another running broken javascript/xml with react native on top.
At the bottom of everything is Sharepoint though.
As I understand it, Sinofsky is largely responsible for this mentality in the various places he worked across Microsoft: he instilled a distrust for anything originating out of other teams.
These days, I think Microsoft's web-based desktop apps mostly use WebView2 directly instead of Electron, so they don't have to bundle a browser. I think for Teams it happened at the same time that they moved from Angular to React.
The point about them not using MAUI still stands though. From what I understand, the .NET world has either adopted different abstractions like Avalonia, or stuck with tried and tested solutions like WinForms with proprietary controls. After all, they've seen this before with WPF which was never fully adopted by MS either, or with the debacle around Metro/WinRT. You're never quite sure what Microsoft wants you to use or will support in the long term. They also make Blazor, which is a different (and likely more accessible) way to build web apps with .NET.
Since we're on the subject of companies not dogfooding their shiny tech, is Google really using Flutter for their own apps? I feel like the evolution of the Android ecosystem towards Kotlin and Jetpack Compose implies otherwise.
Ive been building these apps (cross platform web based ui, C# backend) for years, and yes its finally good to see MS catch up and validate the architecture ive pushed since Xamarin. I wrote once wrote an electron version of this archand thought wtf are people doing? Things can be so much easier when you use a platform that knows how to multi-thread. At stages i had to build adapters/upstream patches for Chromeiunium directly onto Mac and Linux, and its was a major pain having to debug C calls.
Ive been using the same framework now for 10+yrs on apps in the stores, i wrote a small layer infront of the webviews and can swap out webkit, chrome, edge on demand. You really dont need much, just a constand way to boostrap logic and UI. 90% of code is shared across all platforms, there are def differences in WebView engines that you sometimes come across but those parts just get swapped out with browser specific JS. Ive found bugs and worked with browser teams at all vendors doing this and to see how simple this is with Dotnet these days compared to when i started is refreshing. Its easily the most stable cross-platform framework around, if you are stuck using something like flutter i pitty you, its just eletron with another skin. I can swap out and integrate directly with OS libs when i need to do stuff that the dotnet team hasnt gotten around to yet without re-writing. This has mean i really havnt used MAUI at all, but if i need to or could take advantage of it i can mix it on an Ui element by element basis. I prefer webUIs though, i have the chose to handle anything with either JS, WASM, or a combination. I can use traditional JS frameworks or traditional Native UI frameworks.
If i had started this process later, avalonia seemed to have the closest thing i required. It was just a bit a more complex /based on WinUI (which i dont really enjoy) but it supported all platforms and gave lower level api access. MS were smart, that canabalanised all these community effort and brought them into the fold. Every dotnet webview impl was a successfull community driven project before. They didnt write anything themselves from scratch.
> Microsoft Team is built on Electron and not MAUI
Microsoft Teams was released in March 2017. .NET MAUI was released in May 2022. In 2021, Microsoft replaced Angular with React and moved away from Electron to WebView2 (using the OS' built-in renderer rather than a bundled Chromium). So even the rewrite was a year before MAUI (and they probably started the rewrite before 2021). Plus, part of the point of using React there was that they could basically replace Angular bit by bit.
Microsoft Teams is just older than MAUI. It's like asking why Hadoop is written in Java and not Go or Rust or why Kafka is written in Scala and not Kotlin. Kafka was open sourced in January 2011 and Kotlin came out in July 2011. Kotlin wasn't an option given that they were developing it years before the language was released.
That's not to say that Microsoft's attitude toward MAUI doesn't leave concerns. There was some news a while back about a bunch of layoffs around MAUI. It's always concerning when there doesn't appear to be any dog-fooding going on - is this just some junk they're throwing at us that they don't want to use? I think some hesitation also comes from the Blazor side where it's looking like Microsoft doesn't really see Blazor as a React competitor so much as a way for internal company apps to be made quickly - in contrast to the Google IO presentations on WASM support for Dart/Flutter where they were emphasizing better-than-JS performance.
That said, Microsoft hasn't really released a lot of new (green field) stuff over the past 2-3 years. What product should they have made in MAUI, but didn't? You can't say Teams because that was a giant product way before MAUI even existed. Most of what Microsoft is doing is work on existing products - things they released before 2023/2024 and were in development before MAUI existed. Flutter had a 5 year head start on MAUI.
But there certainly is a feeling that Microsoft doesn't feel committed to it or at least not enough to put its weight behind it.
Teams is not older than MAUI because MAUI was mostly a rebrand of Xamarin Forms.
This. Xamarin is MAUI. Xamarin was founded in 2011, acquired by Microsoft in 2016 (a year after Flutter was created).
Microsoft seems more committed to react native than MAUI.
Never build a frontend on a .NET technology. Period. They always end up unsupported in the end. Just use standard web technologies and thank yourself later. I've been a .NET dev for a decade now and that's what I've learnt.
Blazor is pretty great. It is mature at this point and MS is using it internally more and more. Trying to go back to something like React makes me shudder. It's not perfect, but it's better than many alternatives.
I agree. For Blazor there is hope. It is standard based (web assembly, HTML, css) and it feels very intuitive particularly when compared to other spa frameworks like react. Also you can reuse all your html, css and design systems you have. Which is huge because like that it hooks up with the whole web development stack.
For as much crap as MS gets, the entire ASP.NET Core stack is an oasis.
Most of .NET is.
Tauri is pretty awesome. Rust backend, WebView front end. Nothing uses native desktop elements of course.
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).
In my experience with Tauri, it's pretty good on Windows, but not so much on other platforms, especially Linux. The decision to target different browser engines on each operating system means you still have to deal with a bunch of different OS-specific bugs.
For Windows you're dealing with Edge (so Chromium), on macOS you have Safari, and on Linux you have WebKitGTK. WebKitGTK has honestly abysmal performance, and you're missing a lot of modern standards.
The Tauri devs are looking at bundling a Chromium browser with it to deal with that, but that's still some time off, and leads to the same issue Electron has, where you have large bloated applications.
https://github.com/tauri-apps/wry/issues/1064
> As far as I can tell, Windows 11 doesn't even have a toolkit with platform UI elements.
They do, it's called WinUI 3. It's barely used for all of the aforementioned.
I tried this. Their examples don't even compile lol
> Rust backend, WebView front end.
I don't know much about it but it seems like a weird combination. If you want high performance and low memory usage, you don't want HTML, if you want fast code writing, you don't want Rust.
I don't believe you generally end up writing a lot of Rust with something like Tauri. It is mostly web dev. While it is true that browser based UIs are slower than native, it isn't clear that .NET based UIs would be any faster while being very niche.
There's Wails for Go backend and webview frontend; https://github.com/wailsapp/wails
Use the slower but easier to write languages for front end is the norm for complex apps. Many apps that passed the trial of time are like that.
Blender: frontend Python, backend C++.
Houdini: frontend Python(PyQt), backend C(presumably)
Sim City: frontend JavaScript, backend C++
The reason is very simple: frontend is more error tolerant, but less resistant to the product designer's whims (or the users' desire to customize.)
> Blender: frontend Python, backend C++.
blender's frontend is pretty much exclusively C++? https://github.com/blender/blender/tree/main/source/blender/...
> Houdini: frontend Python(PyQt),
I would be infinitely surprised if Houdini's frontend wasn't also a majority C++. Likewise consider large apps such as Ardour, Krita, etc.
I could see a case where the core logic needs to be performant, but the UI does not. The front end could be some menus, displaying (not a giant amount of) data, and a progress bar, while the back end does heavy computing.
And furthermore, if you want fast code writing, you write in the language you already know. For some people, that is Rust.
A very reasonable combination:
- HTML is the main way of designing interfaces (whether we like it or not)
- Rust is the main language promoted by intelligence agencies with multi-billion dollar budgets because it is laced with their backdoors (whether we like it or not)
As wrong as it feels to have to use Electron for a desktop app, it really is the safest approach for most applications.
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 really is the safest approach for most applications.
It's also the option which gives your users by far the worst experience. Not worth it at all, imo.
Not really. The downsides are mostly overblown.
Plenty of category leading applications like Discord, VSCode, Slack, Figma, etc. use it quite successfully.
All of those are examples of overbloated, slow, horrible user experience apps.
Does their market share back up your take of them as horrible apps?
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.
Users will happily deal with a suboptimal experience as long as there are other things attracting them to the product. That's why Microsoft can do whatever it wants with Windows without worrying their users will run off somewhere else. So if you care more about people than businesses, maybe it shouldn't be an excuse to pick "better dev experience" over the user's.
Beware with that logic. You notice successful electron apps because of how bloated they are. I suspect you use many Qt apps without even noticing.
One that comes to mind that I use daily and noticed only recently that it was implemented in Qt is the telegram desktop app.
They said horrible user experience apps, not horrible apps. You can still deliver an app with a horrible user experience and build a profitable business. Ever done an expense report?
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.
Discord, VS Code, and Figma are all apps that individuals choose and are well liked despite many alternatives. Slack too I think, though I don’t have experience with it.
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.
They work great for me.
Oh yes, the great old "works for me". On a yesterday's supercomputer, I presume? I live in a "developing" (have doubts it's really developing) country, most people are running laptops with no more than 8 GiB of RAM (sometimes it's 4 or less), and all this Electron nonsense is running like molasses, especially if you're trying to use a computer like a proper computer and do multitasking.
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.
Hey, I found CEO of Discord
All of those I avoid using due to their slowness. I can notice text-input lag in vscode ffs!
>As wrong as it feels to have to use Electron for a desktop app, it really is the safest approach for most applications.
> 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.
> Qt also seems to be a good option
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.
They are building more language bindings to back QML frontends
https://www.qt.io/qt-bridges
Thanks for sharing. I hope that initiative goes well. And again, integration with whatever solution the language has for hot reloading is a must these days for UI development.
For what value of “safest”?
Same for me. I used to do desktop dev with MFC and WPF but these days you would be suicidal to build any app that needs to last for a few years on .NET. If totally needed, WPF is still the best bet. Otherwise I am pushing everything I can to the web.
I sure never will write a single line of JS/TS again now that Blazor exists and is stable.
So you've never used WinForms, WPF and MVC
MVC is not .NET of course.
You are right that WinForms and MVC have been around forever. However, Microsoft has continuously told devs that they are the past. So, you would be forgiven for expecting them to go away.
WinUI is the current official desktop paradigm and it is basically UWP from an API point of view. So the idea that UWP went away is not 100% accurate either.
Microsoft does not really abandon their UI tech like people say they do. But look how many different frameworks they have.
All of the above is Windows desktop only. There are a completely different set of UI technologies for the web.
UNO Platform (Open Source) allows you to use the WinUI API to target almost anything.
.NET MAUI is the official "cross platform" UI tech from Microsoft. It is what you use to target iOS and Android. As a bonus, you can target macOS and Windows too. On Windows, it uses WinUI. You will notice that the Linux desktop is missing from that list.
Here comes Avalonia to build MAUI on top of the Avalonia framework. This adds Linux and WASM to the list of platforms that MAUI will run on. Adding Linux is awesome. A lot of people have wanted that and it really completes the MAUI cross-platform story.
Adding WASM is neat but MAUI was never meant to target the web. If you use it for that, it is literally just the modern version of Silverlight. But Microsoft did not design it for that at all. It is just a back-end that Avalonia supports.
> MVC is not .NET of course.
https://en.wikipedia.org/wiki/ASP.NET_MVC
MVC is a design pattern, ASP.NET MVC is a framework that used MVC as its go to pattern. But MVC is not in any way only ASP.NET MVC. There are plenty of other UI frameworks that use MVC and the Wikipedia article lists a lot of them for example: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93con...
I feel like they're both talking about MFC instead..
Except WinForms, spectacular for Windows-only utility GUIs.
> spectacular
Not exactly the word I'd use, since it really hasn't changed since VB4, but it's definitely reliable and stable.
WinForms came way after VB4 and it was a .Net only technology.
No kidding - kind of wild that winforms is still kind of a gold standard experience today! I actually liked VB Forms - lots of easy rapid application development was possible.
Delphi was the best RAD tool though. It was native code, not a weird interpreted or jitted app. It could also build to a single exe file. VB struggled with an unwieldy engine for most of its life.
WPF as well
I like WPF and I code with it regularly, but the drag and drop UI builder was the worst aspect of WPF and generated terrible Xaml that was almost impossible to maintain.
I was going to suggest the same, just use WinForms. It's basically feature complete, and it's going to be the last UI framework Microsoft is going to yank out from beneath you.
IIRC, because of Wine, Mono has enough of WinForms to make a few things work. But who the hell wants to distribute an application with a Wine runtime?
Generally speaking, I wouldn’t take what Microsoft uses as guidance nowadays, given a lot of the software they produce. (This is not an endorsement of MAUI.)
That has been a problem since forever. Microsoft themselves rarely used the tools they gave to developers. SourceSafe, MFC, WPF and the .NET frameworks that followed were only for 3rd party devs. And when they used these tools, the software usually got worse. One example was Visual Studio. 2008 was really nice with great customization and good performance. Then they wrote 2010 with MFC and it was slow and lost tons of features.
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
You are mixing your UI frameworks and versions. VS 2010 is written in WPF. WPF is / was Windows Vista's and 7's UX. Old Control Panel in Win 10/11 still is WPF. All the wizards like ClearType wizard is WPF. MFC is much older (1992).
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.
Everything you say is using WPF is not actually using WPF, other than Visual Studio.
Oh yes. I mistyped. 2010 was written in WPF
Why invest strongly in a desktop-first framework when society aren’t too sure about it?
MAUI was to get them through to where everyone wants webapps - served from an Azure backend, of course.
MAUI was horrible when I tried using it about a year ago, tons of bugs, pretty iffy comms/support from the MAUI team as to timelines when things might get fixed, etc.
Eventually dumped it and moved to Kotlin Compose/Multiplatform, which is just so much better at achieving a similar goal (though, obviously, without being part of the .NET ecosystem).
microsofts own stuff never seems to be what gets momentum. there's a strong aftermarket for better ways like back in the borland era bcb and delphi, the more things change the more they stay the same!
In case anyone is confused
> 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.
Is it like Flutter?
Is Flutter like WPF?
No.
> We are collaborating with the Flutter team at Google to bring Impeller, their GPU first renderer, to .NET. That work is already in progress and as it lands, the MAUI backend will inherit those gains.
Interesting, I wonder how good Impeller is and if it's actually better than the new Graphite backend of Skia.
More info here [1]
the big difference is this
or as described here [2] [1] https://docs.flutter.dev/perf/impeller[2] https://medium.com/@raiden.lpf666/skia-vs-impeller-a-perform...
Yeah, buts that's compared to the older "ganesh" version of Skia. The new "graphite" version purportedly brings all those same advantages.
This is actually really good news, as impeller was built to replace skia. Its one of the best technical bits in the flutter stack in my opinion.
Impeller is designed with mobile apps in mind while Graphite is designed with desktop apps in mind.
I don't think this is correct. Chrome uses Graphite and their biggest supported platform is Android.
My kingdom for a UI toolkit that can be used to make real CAD programs, and not yet-more things that just look like webviews and could just be a webpage.
This 100%. I hate the trend of UX/UI that got unleashed upon us in the last decade of the web. Everything is scaled up for touch interactions and has to have fancy animation and very "comfortable" spacing around elements.
I wish we can go back to UIs that focus on information density and usability. I love looking at Japanese websites because of this.
Why do you hate it?
You can make CAD programs with any toolkit as long as you have a GPU surface to render your actual CAD output to. You can do anything with this toolkit from weather apps to video editors, map analysis, and PDF editors.
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
GPU surface is one thing, but I believe OP means the actual UI controls: buttons, tabs, combo boxes, data grids, multi-window support, etc...
I don't think that's a problem? The .NET library this is about, that now supports MAUI code unchanged, is already used in programs like https://github.com/sourcegit-scm/sourcegit/blob/master/scree... and https://github.com/GPUOpen-Tools/GPU-Reshape/blob/main/Docum...
This + a reasonable data transaction layer that supports undo and reasonably large (multi gb) data structures.
You could look at Godot. Their own editor is made with Godot’s own UI toolkit and in a CAD application you probably don’t care about some of the downsides this would entail for a CRUD app (accessibility, perhaps text layout etc.).
Yes, that's my litmus test for GUI toolkits - is it suitable to develop Photoshop-like software? Or is it only good for yet another weather or todo apps?
Yeah, oddly Avalonia mostly passes that litmus test, but this added MAUI layer doesn't.
QT?
WPF & WinForms are also still around
I'm currently in the process of creating a piece of development software and needed a cross-platform GUI environment to do it with.
I first tried Maui because its seemingly so highly rated and recommended. It turned out to be a complete nightmare. Even just installing it didn't just work, I had to spend 2-3 hours just to get that going and then when trying some basic things for my UI it turned out to just not be supported.
The next on the list was AvaloniaUI and wow, it was the complete opposite experience. Installation was a breeze and with only a marginal bit of googling I managed to do all kinds of things such as making a top-most only borderless transparent window etc.
The interface in Visual Studio could be a bit better overall, but compared to Maui its light-years ahead.
Finally, finally, I can use something apart from Kotlin Multiplatform and Electron to build slow alien-looking applications with annoying animations and phone-styled UX for Linux (and, let me guess, there is no native Wayland backend). Of course the set of widgets is comprehensive - there are button and checkboxes, what else might we need.
I'm wondering why all the demos of modern UI toolkits look and feel worse than Delphi 1 demos from prehistoric age.
Avalonia does not have a Wayland backend now, but they say it's a priority: https://avaloniaui.net/blog/bringing-wayland-support-to-aval...
I'm sure there's a better place to track the progress on that.
If I remember correctly, it's a priority for like 5 years or so.
You can (and could have for a while now) just use Avalonia natively. It supports Windows/Mac/Linux/WASM natively already. I think this work is primarily for those who already have MAUI apps and want to target Linux/WASM from an existing codebase.
In case anyone cares:
I go to "Launch MAUI in your browser" [0] in section "Try It Right Now". I click on "Word puzzle - A word puzzle game", third of the demo apps. I click on the "Randomize" button. Tiles start shifting around. I click on the left arrow at the top to go back to the main menu. The whole thing becomes locked with the word puzzle on the background and the main menu on top of it. Nothing is clickable any more.
This happens on various different browsers.
[0] https://brave-sky-0c7a41a03-preview.westeurope.3.azurestatic...
Yeah the shuffling takes ages. Once it's finished you can go back. Also the movement of the tiles feels very strange with the mouse. The Click-Drag sometimes works and sometimes doesn't. No visual feedback is given on click. The tiles don't move but teleport, which is strange for a click-drag interaction. A simple click would have been better, or a move animation. Someone else noticed it, too https://news.ycombinator.com/item?id=45893986#45897805
Tried the calculator:
7/9 = 1
Tried the RPN calculator:
Can't push any numbers to the stack, so I can't use any operator.
[dead]
It seems like alot of people in this thread dont undestand the dotnet stack. MAUI, Native UIs, and WASM are all interchangable. Your cross platform app could literly be built out of everyone of of these components at once. MAUI is not required for use-cases generally when you have a webUI, its really targetting at the simple UI, write-once, run anywhere crowd. Once you outgrow it, you can move to native integrations using dotnet linux/mac/windows. Or you can just integrate with webviews, and have C# backend's or WASM backends. The combination is limitless.
Xamarin turned into dotnet, Xamarin.forms turned into turned into Maui. Name another large tech company that has embraced community projects like this and pushed provided enterprise support for community driven stuff over the same period.
I was writing cross-platform apps before Flutter, angular, or whatever other language you choose for 11yrs now. Find another framework thats done this before the scare tactics of "MS will abandon this" rhetroic. dotnet is the premier cross-platform enterprise ready framework full stop. No other framwork has the backwards compatiblty while maintaining paritity with the latest OS APIs. No other framework can serve millions of pages per/sec while supporting pixel perfect UIs and code-reuse. They have invested so much money in building automation that means as soon as the OS releases an API, your getting access to it. In real world terms, this is what counts if you want to build cross-platform stuff that your clients cant tell isn't native.
I run the same code from 2014, today, in apps in all the stores. Over the years all i have had to change is various namespaces to take advantage of the latest enhancements. Code that ran on dotnet4, silverlight, xamarin, still runs today on dotnet10. I share 90% of code across all platforms yet clients cant tell they are not native apps. Thats what i call return on investment.
I agree that, despite all the complaining, code re-use and longevity on .NET is second to none.
Where there is intense confusion in these comments is in thinking that MAUI is a web application framework. MAUI is "cross-platform" as you say but really mobile first with desktop brought along for the ride. It is in no-way intended to be a web application tech.
Avalonia has created an Avalonia back-end for MAUI which means running MAUI apps wherever Avalonia is supported, and that includes WASM. So now you can run MAUI apps in a browser. You can but that does not make MAUI web tech.
I can run Windows 95 in a browser. That does not make Win32 a web API.
MAUI has felt like a barebones project for years. Forgive me if I don't believe this is the beginning of more robust support.
Microsoft acts when it feels competitive pressure. I think Google's Flutter has been validated so Microsoft feels the need to respond.
Dart is a wonderful language though. I'm not switching back to using .NET anytime soon.
I wish it was a real "systems" language as well, i.e. not single-threaded/javascript-mindset one. That's why I hope someday we will have a nice cross-platform framework for Swift.
I whish that too, but I'm not holding my breath since Google needs Dart-to-JavaScript compiler, which will continue limiting features Dart can implement. The only way this can change is, if they move to WASM and drop JavaScript target.
I love Dart, which I consider to be Google's C#. Either language is fine with me.
Go is google's c#.
Dart is much closer to C# than Go is
Originally, C# was more like Dart, but modern C# is like both Dart and Go combined and that's (IMO) the beauty of it.
Newish low level features of C#: https://em-tg.github.io/csborrow/
Go is frankly the polar opposite of C#. Go compiles to a native binary with no runtime dependencies and it relies on simple garbage collection and static linking. C# runs on the .NET runtime which is heavily managed, gives you JIT, reflection, dynamic code generation and so on. Go views concurrency as fire and forget, C# views it as compose and await. Go is extremely explicit while C# is extremely implicit.
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).
C# has AOT compilation which creates a single, native binary. This has gotten so much better with .NET 10 and since the introduction of source generators to deal with reflection issues.
Also, check out nanoFramework for a .NET runtime that can run on MCUs like the ESP32 [1]
[1] https://github.com/nanoframework/Home
Cool, I didn't know this. I see it's been a thing since .NET 8, but it also looks like something that is perhaps mostly meant for hobby projects? Or maybe I'm getting that wrong.
Definitely started that way for me. It was cool to see a console app written in C# be compiled straight to native and run. Since then, a lot of work has been done to make AOT viable for more workloads.
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.
.NET can be compiled to native binaries. .NET can be used for embedded development.
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.
Cool I didn't know about it's AOT, but it looks very... well hobbyist. Anyway, "Go is more explicit and more verbose" is a feature, but that's a matter of personal taste.
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.
What would be to point of switching from Kotlin + Composel (Multiplatform) to Dart + Flutter ?
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 ?
I don't think Avalonia is actually affiliated with MAUI or Microsoft either
The demos barely work for me at all on Chrome.
The sliding puzzle is really finicky, have to try multiple times to slide stuff, the top left (back) arrow stopped working altogether until I refreshed the page, which of course takes you back to the original page... The time picker looks awful with the numbers not centrally aligned to the control (they look too high), and it's finnicky to use / same with the date picker.
Awful.
It also locks the entire app when you go back during shuffling
https://news.ycombinator.com/item?id=45893986#45897572
Avalonia is also working towards using the new Flutter rendering backend Impeller which is being used to replace Skia, which is used by Chrome for rendering, turtles all the way down:
https://avaloniaui.net/blog/avalonia-partners-with-google-s-...
So like we're really just going to do this every decade or so with a new runtime until people remember they hate it and start over?
My exact reaction
These kind of announcements always suffer from 'creator knowledge bias' and never define their terms ;-)
"What is the Avalonia MAUI Backend?
At its core, the Avalonia MAUI Backend enables you to keep your MAUI codebase while replacing the rendering layer with Avalonia."
Which tells me exactly nothing. what even is MAUI, maybe some polynesian deity? :-P
I know, I know, I can google stuff. But still...
The announcement is geared towards .NET devs. If you're reading Avalonia blog posts outside of HN front page, you definitely know what MAUI is.
In this case, think of MAUI as a way to define a UI in XAML (ie XML). Avalonia is a way to compile that XAML to actual rendered views on the platform.
Took more than a minute to load on my macbook. Ouch!
I really love C# and the .net ecosystem, but they just haven't made it work for web.
Blazor is incredibly productive.
I wouldn't use it for consumer apps because it requires a Websocket connection to maintain state and probably doesn't scale very cheaply... but for business applications or personal tools it's actually kind of insane how much functionality you get out of the box (at least by the standards of statically typed languages).
To replicate this example in Typescript, I'd probably still be installing packages in the time it took to write the 20 lines of code it contains: https://learn.microsoft.com/en-us/aspnet/core/blazor/compone...
.NET works amazingly on the web. This is just not the UI framework you would use.
There is ASP.NET of course and Razor Pages. We all use apps built with these every day without even realizing it. There are other great frameworks as well.
I do not even see Blazor as a real web technology but of course it is positioned that way.
MAUI is a "cross-platform" and frankly mobile first UI framework. It was never meant for the web.
Is there anything we can do to stop it? Or will it come anyway?
You can make your own better system which supports GUI and provides a reasonable runtime that works on all current major platforms and provides development tools, years of ecosystem development, etc. etc.
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?
Anything would be better than another UI toolkit made by Microsoft. They will abandon it in the matter of a few years like they did about 10 times already.
They may not be improved significantly now, but none of the toolkits got abandoned. You can still use anything from Win32 to MAUI today for a new app.
I started moving to using GO and Fyne for cross-platform GUI tooling. GO 1.21 supports Windows 7 with Fyne. Ya still have to support Windows 7 for work. No more wasting time with managing a Windows installer.
QT Framework is still one of the best for cross-platform desktop applications when speed is key.
Searched the docs: No results for "Accessibility"
(Which is ok for some situations, but not for wide deployment like .net provides)
Like I said tooling. Means that the User is well defined where Accessibility is not an issue. The tooling I creating is for people that have to engage with physical equipment; from replacing parts to making sure a motor is working properly.
Why tho? We really need Silverlight reborn.
Also C# and .net overall are so damn good.
Anything to abolish the js and constant hacks upon hacks
I want WASM+DOM so that we can use any language on the web
Beside already mentioned, there is OpenSilver[1]. Supports Silvelight and WPF. Renders to DOM+WASM. They are also planning support for MAUI.
[1] https://opensilver.net/
WASM and DOM in Rust: https://www.leptos.dev/
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...
It looks like it comes just as a wasm payload, so, you can only vote with your feet.
If React is what’s powering the start menu now, I’m more curious about why Maui doesn’t power the start menu.
.NET Maui running on windows seems like a more logical first step to prove the organization buys their own dogfood.
> If React is what’s powering the start menu now
To clarify, it's using React Native XAML, where XAML is Microsoft tech for building UIs. So they are dogfooding but they have too many UI frameworks to choose from.
You wouldn’t use MAUI to build something for only one platform. You would just use whatever it’s an abstraction over for that platform which in the case of Windows is WinUI.
It's a nice idea, but the execution is taking the wrong path in my opinion. By rendering everything to a `<canvas>` they're sacrificing any hope of accessibility and compatibility with browser standards for UX.
I would have much preferred a React-Native-style approach, where they render to true HTML instead. Even then, WASM files are too heavy for quick loading times without good internet (and sometimes even with).
The projects I see that would most benefit from something like this are complex internal apps that need to be used in different places but aren't worth porting over/rewriting, but they would also suffer from terrible UX given the constraints of this design.
For all other projects, it makes for more sense to use React Native.
It's not meant to be an HTML renderer. That's for .NET apps. While it's cool they can run in a browser, that's not meant to build websites.
Would you complain that Qwasm/Dwasm doesn't follow HTML standards of accessibility?
Accessibility is for all user experiences, not just websites. WCAG is still a good resource for native apps even where some specifics do not 100% apply.
If Qwasm is referring to Quake, it absolutely should have, for example, legible color contrast and be usable if you are colorblind.
What else do you build on the web with a UI framework if not a website? If you're making a distinction between websites and webapps, it's equally important for both to be accessible and work as expected with a browser.
vscode?
VSCode is a webapp [1], that is most often used wrapped in a shell that lets it act as a desktop app.
Even if you do consider it separate from webapps, it should still work with tab navigation and screen readers, which rendering to `<canvas>` doesn't allow for (at least without some very hacky workarounds).
Flutter faces a similar problem; to render cross-platform, they use a custom layer not standard to the system, and then try to emulate all the behaviors of a native app, which often feels broken and unnatural and is wasted work because the engineers are just rewriting and reshipping everything the platform already offers—at the cost of accessibility and general user experience.
- [1]: https://vscode.dev
Silverlight reborn
Edit - for those unfamiliar: https://en.wikipedia.org/wiki/Microsoft_Silverlight
Open the demo... takes forever to load... open first app, calculator... looks awful... presses back (Chrome on Android)... back navigation is broken and it leaves the whole app returning to the previous website.
This could have been so much better.
Why does everything need to have a soulless mascot now? It’s offputting.
It's great to have .NET ecosystem expanding. I am a .NET dev, and I still use web optimized for mobile as my mobile platform(where applicable). Tried MAUI and all the other stuff, just doesn't cut it for me. You can make an app using it, but I would rather not to. The best 'mobile platform' for me was blazor hybrid, but then again - if it's already blazor why not go full web...I guess it depends on the 'seriousness' of your mobile application. If I had to develop a complex mobile app, I might choose another language framework, cause MAUI uses XAML and MVVM stuff that is quite a big overhead IMO.
Building MAUI with Binding/Layout/Themes on top of another engine with Binding/Layout/Themes doesn't sound efficient.
Plus, it is my assumption/understanding that there's no way 3rd party controls will be able to run on Linux/Browser unless they're built directly against MAUI API without any Native our Skia dependencies, which is almost never the case from the libraries I've been using.
Am I right?
Would be interested to know about the a11y story on web and other platforms. Does it integrate with screen readers, accessible navigation tools, a11y apis, etc.
This is somewhere quite a few tools fall down. For example, for web: Rendering to canvas doesn't create the dom nodes required to hook into the tools, and creating the nodes appropriately can have a significant performance impact.
What about native a11y tools and tech.. there are some ios specific ones that you'd expect on an ios app for example.
I don't know if it has since improved, but .NET MAUI was really, really rough when I created a mobile app for my employer last year. I'm talking basic things - changing basic colors on the toolbar (1), putting non-text content inside a button (2), basic trigger behavior (3), to list a few. Not to mention that .NET UI has been years behind on hot-reload and developer tooling. Additionally, It was a fight to keep our app performant. The XAML compiler is a step in the right direction, but we had relatively simple views (in the dozens of components) absolutely tanking our FPS. I know there is probably some of my skill issue in there, but when I find basic things taking hours to optimize that I wouldn't even think about in React, I start to wonder about the framework. I spent a lot of time creating PRs on .NET MAUI but their team appears quite small and overloaded. I wish them the best - they're some talented folks, but I don't envy their job.
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
Well, I guess Avalonia can solve 4 at least as you can negate a binding[1]. Good news for me as I recently started an Avalonia project, and thought you did still need an InvertedBoolConverter.
[1]: https://docs.avaloniaui.net/docs/reference/built-in-data-bin...
A toolkit announcing “Linux support” is pretty ambiguous. Does it mean Xorg support? Wayland support? Framebuffer support? The announcement provides no clue about this.
They are not announcing Linux support for Avalonia. It has long supported Linux.
What they are announcing is being able to run MAUI on Avalonia such that you can run your MAUI apps on any Avalonia supported target. This includes both Linux and WASM, neither of which is supported by MAUI directly.
Since it's using Avalonia, I'd say it's just X support at the moment. They've announced that they intend to support Wayland, but that was a couple months ago[1], so I doubt that's ready.
[1]: https://avaloniaui.net/blog/bringing-wayland-support-to-aval...
A while ago I was at an agency and we got a client that was a very popular weather app. Things like mapbox and some analytics libs (can't remember exactly, this was 2019) The project was a big redesign of the app. We looked into using Xamarin to see if we can at least write the core logic in C#. The issue we ran into is that there were many third party libraries we needed to import that weren't converted to Xamarin/C#. There was a way to try and have it automatically bind but never worked properly. In the end we just went pure native. Turns out Xamarin was a fun toy framework but Microsoft couldn't point us to anything serious and battle tested in production written in it.
I'm curious to see if .NET MAUI will surpass Xamarin and actually get serious adoption. They have to figure out the third party binding issue.
What is the future for MAUI, anything changed in last months?
https://www.reddit.com/r/dotnetMAUI/comments/1l1xiib/entire_...
This is awesome… but: On the Web, is Avalonia using Skia to render inside a Skia Canvas?
**insert inception meme here**
Joking aside: this points to MSFT moving away from the whole Mono/Maui investments and into Aspire or whatever they call it. Without MSFT backing this I am not sure if there is much more future left for MAUI (or dotnet on mobile in general).
Avalonia is great though.
> On the Web, is Avalonia using Skia to render inside a Skia Canvas?
Yes. They're also looking at offering Impeller as a render option:
https://avaloniaui.net/blog/avalonia-partners-with-google-s-...
I clicked a total of three times in the demo page before the tab froze and locked up.
MAUI is nice, and I'm glad it's getting decent Linux support now, but I would never use it in the browser.
Avalonia's big money ticket is taking old WPF projects, making minor changes to the XML to load their tools, and instantly making the projects work on macOS/Android/iOS/etc. (for an enterprise fee, of course). Great for forcing internal .NET applications built to run on Windows Vista into the modern world, but I don't think their web platform is a good idea for new projects because of the massive overhead you end up with.
Imagine how popular WPF would get if MS bought Avalonia and made it free
isn't it already free? Afaict it's just some tooling that's not free.
> Launch MAUI in your browser →
This is absolutely horrible and I hope I never have to use it on the web - right click doesn't work, my plugins don't work, I can't even open DevTools and when I manage (before the app has loaded), it's just a <canvas> element in the page. I know a lot of people put work into this and something is probably better than nothing, but actually no, I think such solutions are disgusting.
If you're gonna claim cross platform, don't just stoop down to the lowest common denominator and write a bunch of pixels to the screen, use the damn system UI solutions, or in the case of web apps - HTML, CSS and JS/WASM. I already take an issue with Electron (Lazarus lcl did things right, in contrast) but realize that it yields a lot of utility, yet these canvas based approaches for web apps feel like a step too far.
Yet obviously nobody can admit that they can't do the heavy lifting needed to support multiple different target platforms for the same widgets in a way that respects the corresponding platforms, while also still wanting to ship something. In this case, I think nothing is better than something, if that something is so bad.
If it runs on Avalonia anyway why choose MAUI? If you have the option just use Avalonia. MAUI is unfinished and its docs is awful.
Do you want to build an app using MAUI? Unless you build an app that barely deviates from the template, expect to desperately search through decade old Xamarin documentation and figure out the details through painful trial and error.
Good luck.
They addressed this.
It is a way to get people choosing the "official" path (ie. choosing MAUI) to experience Avalonia. They are hoping you come for the MAUI and stay for the Avalonia and become an Avalonia developer.
As for, why choose the Avalonia version of MAUI, there are three reasons: - Linux support (the big one I think) - Drawn framework (same renderer on all platforms) - WASM support (probably useful sometimes but not the real draw)
They are making a big deal of WASM here because it is easy to demo. We can all go into it and run it. But do we want to use it for our apps?
As for, why not Avalonia directly? To loop back to the beginning, it is because you do not yet know Avalonia and trust it. The Avalonia team is hoping this helps with that.
Thank you for explaining this. I didn't even realize this was an Avalonia project until you pointed it out. I like Avalonia (and love .NET in general), but I think the messaging on this needs a lot of work. Avalonia is creating unnecessary cognitive dissonance by emphasizing MAUI, which is a competing project after all.
This is what mystifies me about this announcement. Avalonia already works fine on Linux, allowing anyone to build a cross-platform .NET GUI application.
MAUI is supposed to be a wrapper around native widgets. The fact that they had to use Avalonia under the covers to get it to work on Linux seems to defeat the point. (Avalonia is a complete UI toolkit, like Qt or Flutter, that owns the entire stack from XAML to pixels.)
https://avaloniaui.net/maui-compare
I've pretty much considered MAUI a non-starter without Linux desktop as a target and even with this, not sure I would consider it over just using Avalonia directly. Of course, it is nice to see this option getting flushed out for existing projects.
Not to be confused with the MauiKit[0], the cross platform UI toolkit that had the name first[1]
[0] https://mauikit.org/ [1] https://github.com/dotnet/maui/issues/35
Does "Web" mean fully wasm (i.e. weird quasi-useless dialect that can't run a lot of code without being specifically aware of it's wasm/webiness) or some combination of that and a server?
Excited about it, but I don't believe it will be good given the previous fiasco with the MAUI initial release.
I hope Microsoft delivers though, we need more alternatives to React + RN or Flutter.
This is a huge win for people using MAUI. The only thing I worry is some performance loss from using Avalonia backend instead of using directly the target platform.
Blazor, MAUI, Flutter/Dart…it seems every few years this things show up and remain largely in flux but not in a good way.
tried the demo in Firefox on Windows and... it wasn't great? clicks didn't register in multiple subapps
Honestly, I feel that everything UI related has gone backwards to the stone age.
I wonder how hard would it be to go back to visual designers like we had with Delphi or VB6. There were flexible layout container components which helped a lot when adapting forms to varying screen resolutions.
Either it takes more than a minute to load or it does not work on iOS with Lock Down mode enabled.
It's using WASM, which Lockdown Mode disables (among other things).
Good job!
Pathetic that MS doesn’t manage to do this themselves.
Even more pathetic that MS doesn’t actually use it for any of their products, so forgive me if I have very little faith in the future of MAUI with all its bugs.
Maybe this has implications for Godot's C# web support.
I never understood these types of things, what niche are they going after?
This feels like it could be a competitor to QT, but without a real-time operating system like QNX, what's the point?
React Native won out over Fluter, Java Applets lost to HTML5 / JS, Framer is much better than Wordpress.
Time and time again, clever simulations on top of the native world are never worth it.
Why Avalonia and not UNO?
Ok, finally catching up to Kotlin Multiplatform Compose.
Not even close.
tThis is another horrible, "lets render everything in canvas" framework so no select, no OS level context menu, no accessabiltiy, can't look up a word using your OSes dictionary, no IME support so no Japan/Korean/Chinese/Thai input, no find, no extensions, because there's no structure to look at, no translation extensions, in fact no translation period. Ugh!
Uggh, here we go again...
“SITUATION: There are 15 competing standards.”
[dead]
More and more of MAUI is abandoned by microsoft. I wouldn't touch this framework with a ten-foot pole. https://www.youtube.com/watch?v=yil7UVeOx4Q
Too little, too late. Desktop apps are mostly dead.
Not in the industry I work in - AAA gamedev. Art folks typically would have two, or even three monitors - so good solutions for docking across them (and still working) are required.
A chrome browser by itself can't work that - it's great for many things, but not for Creative Tools.
MAUI is first and foremost a mobile UI framework. It was built for iOS and Android. The desktop is added on as a bonus so that you can target macOS and Windows as well.
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.
Desktop UI toolkits are dead or stagnant but the desktop ui is still king IMO
I would much rather see web apps become canvas rendered WASM versions of desktop apps than desktop apps become webview apps. Latter is what we have been seeing in the recent years unfortunately.
Canvas rendered cross-platform UI frameworks like Flutter & Avalonia targeting browsers (WASM), might shift the balance back in favor of desktop UI.
That's why desktop machines and monitors can't be given away. Nobody wants them /s
Three apprecitions:
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.
It wasn’t magic circa 2008-2010 — see silverlight
Agreed, Silverlight was an unfortunate path to choose, a Flash competitor when Flash was dying.
Really... You just had to bring up politics in this discussion?
Out of respect for Miguel de Icaza, yes