Three decades of experience talking here: If you don't see a vendor like Microsoft using a GUI framework for at least 50% of their new applications, then you've made a terrible mistake in adopting it yourself.
Microsoft uses Google's framework for their own applications: Electron.
Yes, you heard me right. Microsoft, a nearly 3 trillion dollar company, uses the framework of a competitor for their own desktop applications.
Teams: Electron.
Visual Studio Code: Electron.
Azure Data Studio: Electron.
Now, let's make a similar list for Microsoft MAUI apps!
> Microsoft uses Google's framework for their own applications: Electron.
Electron is built on top of Google's Chromium but developed by a completely different set of people at GitHub initially for their text editor Atom. Later GitHub got acquired by Microsoft.
To give more context, MS basically forked Chromium/Chrome as Edge, so if somehow Google would close off Chromium they wouldn't be left standing in the cold.
That said, OP's point is crystal clear, these silly new platform projects are the busywork of vestigial orgs.
I completely agree. Evaluating a decision like this, one needs to look at it from a business perspective, in order to reach the correct conclusion. Looking at it like this, what I cannot see is Microsoft's commitment to this technology. Instead, we see a consistent commitment to an alternative technology, even if historical reasons also take place.
Foundations don't really do maintenance on products. Electron is maintained by a few people at Slack at one or two at Microsoft. Of course if you count the Chromium codebase then it is indeed "Google's framework" and they do nearly all the maintenance.
Not sure if this is trolling but Electron is a big open-source community project NOT "maintained by few people at Slack and one or two at Microsoft", you can easily check that by going into repository insights and seeing the correct information which for the last 30 days is "25 authors have pushed 52 commits to main and 267 commits to all branches".
The Chromium take is even bolder, it is indeed NOT a "Google's framework", and it was maintained by at least 1600 authors most of whom are not from Google [1]
Most of those authors are drive-by fixers. Go scroll through the commits list and look at the affiliations of those who are doing the regular work. But watch out, a few of them list OpenJS Foundation but actually work for Microsoft.
The Chromium stats are misleading for the same reason. Almost all commits are made by Googlers. There is a long tail of contributors over the years outside of Google but that doesn't mean their contributions are equally sized.
Yes, but there are 15000 forks of the electron by individuals, even with contributions being not equal, it is still a community project owned and used by individuals and smaller groups all around the globe, not only Google or Microsoft. The same applies to Chromium. The fact that MS is the biggest maintainer now is not a coincidence because it is in their genes to constantly try to take over the good stuff to commercialize under their brand.
The weird thing about MS is .NET in general - it seems like since the inception of the technology they intended to bet the farm on it as the desktop development platform of choice, yet the only first-part MS app that uses it Visual Studio (and assorted tools like Expression Blend).
Which is super weird, since it was conceived as a Borland Delphi competitor (they even hired the guy who created Delphi, Anders Hjelsberg, to design C#), and there used to be tons of Delphi apps.
Electron is owned by Github which is owned by Microsoft tho. They also own npm and typescript. So Microsoft themselves has been moving away from native apps a long time so your main point is still valid.
Not as simple with Preview versions on Windows. I don't think they use Electron whatsoever anymore, and old versions weren't fully Electron either (I remember seeing Chakra [their old JS engine] in the stacktraces, doing some elementary logic), I think it's XAML with UWP + WebView2.
This to me was the biggest strike against MAUI. Teams team recently decided to switch tech stacks to address poor desktop performance, and explicitly didn't pick MAUI.
Immature isn't the right word, MAUI is mostly a rebrand of Xamarin.Forms, which has been a thing for almost a decade now and already had some support for desktop before the MAUI effort. Rather, it's an irredeemable mess.
I remember a similar argument against Visual SourceSafe[0].
We had been using SS since it was done by OneTree (borged by MS).
MS used an internal tool, instead.
VSS did do one cool trick, which I have yet to see replicated elsewhere: You could construct "artificial workspaces," composed of elements (down to individual files) in other workspaces, so, when you checked out (it was all checkout/checkin, back then), you actually checked out from (and back into) the original workspace.
Svn externals provide similar capabilities, though I don’t remember if an external can be an individual file. TortoiseSvn on windows made it not to painful to use.
My memory of VSS was that it locked files while you were making changes, and that stopped your colleagues from editing those files until you were done.
That, and the slow speed, were my two memories of the product. But I admit the last time I used VSS was back in 1996, or so.
> If you don't see a vendor like Microsoft using a GUI framework for at least 50% of their new applications, then you've made a terrible mistake in adopting it yourself.
!! _That is exactly_ one of the reasons why I jumped from Windows to Mac! Back in the Windows 8 days. So much more consistency API-wise and much less fear of your favorite thing being abandoned!
Apple actually uses their own shit, unlike Microsoft internal warfare that would make the Sengoku period seem like a kiddy playground.
Why would everyone start using MAUI if there is a more robust community alternative around? They only develop this because they have resources to do so but no one really needs it. It is a classical Microsoft theme to have their own not-used copy of another popular thing just in case they will have an opportunity to extend, embrace and exterminate it someday.
I can't name a single application of Microsoft written in windows forms, but it is/was still pretty well-supported.
Also: Electron is for desktop apps, MAUI is for mobile apps.
Microsoft hasn't really dogfooded their own external facing GUI frameworks in forever. It's not a great look, but to some degree it also made sense. These frameworks (especially the dumpster fire ones) are .NET/C# (usually with XAML) frameworks, designed (it feels like) primarily to build line of business internal applications, with cross-platformness tacked on in more recent years. The grand-daddy of all of these would be WPF (all the way back in 2006).
Basically Microsoft's flagship non-developer apps (ie Office Suite) is its own little kingdom. They never bought into any of the developer facing C# frameworks that MS created (makes sense I guess?... Office isn't a C# code base). Office basically developed its own visual language and internal framework.
Visual Studio itself actually got some WPF back in the day (though I understood the code base to be kind of what you expect of something of its heritage). I imagine it still has WPF to this day.
Their newer apps - especially the ones that are actually trying to be cross platform (like Teams, VSCode and friends). Well, Teams has the excuse that they need a web version anyways, so Electron really does make sense (see Discord and Slack).
VSCode... the first version of VSCode came out in 2015 (omg..... it actually released a few months before Windows 10). MS had no in-house cross platform solution at that time. At that time, they did have a partnership with Xamarin (Xamarin would later be acquisition). .NET MAUI is the evolution of Xamarin. But Xamarin I always understood to be a bit of a dumpster fire. I was evaluating our choices for a small windows desktop app back in ~2015-2016. Xamarin did not seem appealing. After a misfire with UWP (another MS footgun I think), we just did WPF (cross-platform not required).
Honestly, I wouldn't expect anything that could even remotely be described as an "IDE" to NOT be based on the VSCode code base now. MS has something -very- good going for it there.
And I guess this is kind of one of the challenges. The part of MS that builds apps, is not really related to the part of the MS that builds GUI frameworks for external developers. And the part of the MS that builds apps does not really want their success to be tied to this dumpster fire.
Ive seen angular with c#, java, python and node backends. Angular though is mostly popular with big enterprise non tech companies, more industry differences than tech differences.
True. Many will dismiss this opinion but that's how it is. The only issues being actively resolved and substantial progress happening is in:
CSS - New units, flex, grid, subgrid, animation, new query methods, view transitions.
JS - New APIs ranging from cryptography to WebGPU, Web Assembly.
If you must give an interface to an application, there's absolutely no match to what web platform can offer in terms of fidelity + ease of use and accessibility.
Sure, you can go bonkers with Flutter, Qt, Swing or other immediate UI libraries but then you're on your own to invent everything on your own.
You can't find like of d3js in Qt, Swing, MAUI or GTK. Not saying some half baked version of some of it does not exist OR is not doable at all in any of the toolkits. Just that you have to do it on your own.
Title should be "Developer yells at .NET MAUI team and expects to talk to the manager because their bug hasn't been fixed in two years".
I hope people can see the hostile working conditions that many in open source have to experience daily. There is no possible way for a small team to scale with the thousands of issues they get and give every single one the same amount of attention. That is why it is so important for people to upvote and engage in issues. It gives the product and engineering teams a way to gauge priority.
There are much better ways to go about ranting about product defects though. Doing it in this way just encourages people to pitchfork. We all know that pitchforking isn't productive at all. In fact, it hurts more than you think it helps.
I agree that it is usually useless to rant about an issue in the first place.
In this case, I can see that they were really neutral and understanding in the very first issue. After two years with little to no progress, I'd say it is natural to vent. Especially if they cannot get out of the situation they are in.
It looks like the original poster needs to use MAUI in their production environment. So they are already dependent on it. Which is to be expected, because MAUI already comes with a go-live license.
Also, I'd like to point out that this is not the pet-peeve of a small indie team. It is the future UI framework of a multi-billion company. If the team is understaffed, there should be something done about. The resources should be available in this case.
The latter part should really be looked closer at. You cannot simply attach a company’s market capitalization to how funded a team actually is. People constantly overlook that. That’s true at many big tech companies too. The assumption harms just as much as pitchforking.
While true, I think the point is a mismatch between MS business strategy (marketing MAUI and the next big thing and officially supported) while not properly staffing. As an end user, you might make tech decisions precisely becuase of the market cap, assuming support and proper implementation.
This fundamentally is the biggest issue with MAUI, no one can trust its not just marketing and going to be dropped...
I think the developer is justified in his self-described rant. He has gone through other channels and engaged with the project leaders directly. He has waited years for the bugs to be addressed.
Microsoft is in the wrong here for selling this as the future and not dedicating the resources necessary to fulfill that promise.
How does getting paid change things? Many big tech companies "sponsor" OSS in this way and they have project backlogs bigger than the allowed limit on GitHub. https://github.com/orgs/community/discussions/9678
Because it implies these are people have far fewer excuses for the seeming lack of care about user feedback than some unpaid volunteer.
Considering many companies have contacts ranging from millions to hundreds of millions with Microsoft, and developer tools are a major selling point for the ecosystem, it's certainly reasonable to be upset that when your organization can't depend on them. It makes planning a nightmare - it may take a month or 5 years to deliver your feature, depending on when the bugs get fixed.
Dev with agency here. There is clearly an issue, but "agile" is not it. "Agile" doesn’t mean "ship unfinished products and never care for issues".
In fact, it means quite the opposite: Start with as little as possible, as polished as possible and improve from there. It's actually quite nice to work with, if every role is on the same page.
few months ago I tried to wrap up a MAUI PoC app from a more junior coworker, who failed to deliver anything working after weeks of trying.
Then I spent two weeks on trivial shit and stuff you expect to work by default (pull to refresh, video streaming, video in list view etc.)
After two weeks of stress, failure and dozen of known issues on GitHub with tons of frustrated developers [1], I rewrote the whole poc in flutter in 3 days.
Keep in mind this was a simple app with two screens and sign in/sign up - the only thing mildly technicall was a list view with videos (video feed).
Literally nothing in MAUI worked as advertised and their showoff apps are ridiculous. The build process takes forever and breaks randomly, iteration is slow and debugging breaks all the time.
This is the exact same experience I've had with Xamarin 5-6 years ago.
Any imaginary gain you think you'll have by being able to share code between client and server will be offset many times by having a sane/working dev environment like flutter (working framework, fast iteration) and the language isn't that far off from c#.
We tried building a greenfield mobile app using Maui because my development partner is a Microsoft tools aficionado. We ran into a big memory leak that was so hard to debug using the primitive tools that it set us back a month. Eventually, we discovered it was internal to Maui (leak caused by a Maui component, not our code) and decided to program native apps instead for the project. Ultimately I think rebuilding as native actually saved us time for the simple app we’re building
It’s counterintuitive, but yes, depending on the project cross-platform frameworks can actually be harder for small teams or one-person operations to manage well because they increase the number of layers in which bugs and quirks can show up in — instead of just e.g. Mac AppKit and Windows Win32 bugs, you’ve now got to deal with those plus whatever bugs the cross platform framework has.
This is particularly true for projects where the UI is not overly complex (and thus, not where most of your energy is going), in which case it can make more sense to do code sharing in a library that’s pure business logic (no UI) and platform independent.
I was browsing the dotnet/maui repo and the vibes over there are not great.
decided to give the framework a quick spin myself and for god sake, this thing is in terrible shape. I built a quick holy grail layout with basic content and it looks completely different on all platforms. basic controls are not working and collections are laggy.
seems that nobody in the team really uses this thing in production or interacts with the community
Microsoft notoriously fired all their QA engineers back in 2014. I would assume that QA is no longer a core competency at Microsoft. I'm guessing that they have testing tasks that are now performed by contractors, but no actual _process_ in place to assure quality. The only engineering process now is agile.
My experience as a QA engineer testing software in agile environments in the last 15 years or so is that my attention every sprint is focused first on assuring that the features implement the user stories, and second that the automated regression tests are written and checked into version control. This automation task is where the majority of my 80 hours every sprint is spent. There is no time to check for bugs by way of, say, ad-hoc testing.
If I'm a contractor, all the buttons are on the screen, and the only issue is that the buttons aren't centered, then I'll enter a bug for the alignment issue as a low priority fix and clear the feature to ship. I might POSSIBLY perhaps maybe add a note to the bug suggesting a workaround by sending an InvalidateRect message to the window containing the buttons, but I doubt it knowing that the developer outside of the team would never read it.
I will absolutely NOT be an advocate for the developer experience and refuse to clear the feature to ship with this bug knowing how tenuous my employment status is, however. I would guess that that's how this bug passes QA in the first place.
We are huge into Microsoft but MAUI is on the no touch list.
After maintaining a Blazor (server-side) app for a few years, it has become clear to me that even if the abstractions are ideal, the tooling may cripple the entire experience.
I don't trust Visual Studio 2022 to not treat me like a piece of shit in a UI style project anymore.
The only project types I really trust to not suck are: class library, console app, and azure function (timer or http triggers).
If Microsoft wants me to give their UI frameworks another shot, then I challenge them to rewrite visual studio itself using whatever proposed framework. Only then would I have faith that someone sorted out all the long-tailed dragons that would bite me in the ass 2 years deep.
What UI framework should I be focusing on in 2023? Should I focus on web-based framework (vis-a-vis Electron or similar platform) or is there something more suitable for desktop UI?
We do web-only right now. No frameworks. Maybe focus on MDN if you think you can get the business done with a webapp. Once you master flex, grid & friends, you will be set free.
If we are still insisting upon native apps, I am growing increasingly-curious as to what the reason could possibly be. Unreal & Unity deploy to the browser. What does your business do that is so special by comparison?
HTML is a bad replacement for a proper UI toolkit, that's the appeal. There are so many problems that good UI toolkits and languages solve that HTML just ignores and always will. But, Chrome gets a massive budget, web apps are easy to deploy thanks to the ubiquity of browsers, and there's safety in numbers, so those things usually outweigh the other concerns. Doesn't change the fact that there is plenty of scope to compete with HTML.
There are some really nasty bugs in MAUI, which are not even obviously reported by error messages. From my experience:
* You can build MAUI application fine, but you won't be able to deploy it for Windows and run it, unless your repository lives in C:\ drive. And I mean C:\ drive, not substed directory to D:\ not additional drive. C:\somePath\ only. The worst thing is that error which you get is completely ambiguous and does not tell where is a problem.
* You would think that you can bypass requirement above by forcing Visual Studio to deploy on C:\somePath\bin? Yeah that works for Windows, Android but does not work for iOS/MacOS emitters, where somebody automatically assumes that all path are relative. So instead of C:\somePath\bin MacOS/iOS emitters will try to build into D:\PathToMyRepo\C:\somePath\bin , obviously ending with an error.
I think that MAUI is great product and I like the universal outcome (deploy for all major platforms at once), but my god, myriad of stupid bugs is very annoying.
> "It seems to me that this is the end for Microsoft's mobile team. They do not fix own bugs, they do not respond to the tickets, the even do not review PRs made a year ago"
That's always been the case with all of their frameworks.
Even if the entire userbase is spitting fire the default position is to double down on whatever stupid thing they're doing or ignoring it. Only time I ever got anything fixed was when I was working for an MS partner and we threatened to become an Oracle partner.
Then again the OSS community is only slightly better and Apple is definitely worse!
Well Qt on macOS is a shit show. I pretty much had to move half my stuff off Mac because two Qt based programs I work on regularly keep breaking every time they update macOS.
Speaking as a former Windows Phone Developer: Yeah, this is roughly what developing for Windows Phone and the UWP felt like. Half Baked Tech Demos with glaring, basic Issues that never get fixed. It feels like Microsoft internally still thinks they are such a monopoly that people WILL adopt whatever they get fed by them and when that inevitably doesn't they never fix all the Issues required to be competitive.
A modern UI Framework of any kind is a massive undertaking, especially when it is not browser based. A modern UI Framework that is not Browser based and gets any kind of traction is almost impossible at this point. The Developer Experience would have to be at least as good as Browser based development and you'd have to show significant progress in cross Plattform development for anyone to care.
I was actually hopeful they'd make it at some point. Browser-based UI frameworks aren't very good on mobile - They had a chance here. But it's a classic Microsoft move to take the potential you have and throw it away.
Correct, I've only heard this from two people and this is only their take. This is not an official position.
But the fact that people within the company are saying this to me directly is enough to get me to believe it.
I wouldn't trust a random person on the internet saying stuff like this either, but even without any inside knowledge, it's just logical that they should try and limit time spent developing two of the exact same product .. and I think it's probably becoming apparent to you as well which one is on the chopping block.
From what I understand the goal at the moment is to get GitHub closer to feature parity with ADO before they start to deprecate it .. so hopefully it's coming.
And obviously, grain of salt, third-hand knowledge, etc.
My thinking is that you should extract as much logic as possible into some neutral format that you can run on any CI platform. Bash, Docker + Makefile, Earthly, python scripts... whatever keeps as much logic out of a proprietary vendor specific format.
Yeah, it's over. Avalonia has blossomed into a functional framework in the time it's taken for MAUI to get to wherever here is. It's basically a drop-in replacement for WPF in terms of controls, to a degree that honestly surprised me. The default styling isn't that sexy, but you can change it, just like WPF, so I'd say it's mission complete as far as ordinary apps are concerned!
I think Microsoft has given up on facilitating application development beyond VS and C#.
Also the foundation for MAUI, the native bindings for .NET are incomplete and broken. Back in the Xamarin days the promise was that "everything you can do natively you can do in .NET" - this hasn't been true for a long time. Most of the new frameworks, especially on the iOS side don't have a binding and Microsoft doesn't have a story for Swift based libraries at all
The problem with using Microsofts stuff is that is half baked all the time and it's hard to fix. I have made an Xamarin Forms app and it was hard to do things that were not basic.
Just use the web platform unless you really, really need to do something specific which cannot be done as a web app.
We're working on a MAUI app at work right now. Although I believe the MAUI developers are doing the best they can with a shitty situation (just not enough developers or QA staff for such a complex project), I can say my experience with MAUI has been horrible.
I'm curious as to whether any React Native devs here have had any similar issues? I wonder if all this crap is just what happens when you're trying to do a cross-platform (native) UI framework. It seems that there are people who love React Native (for example Theo Browne) [1]
Glad I dodged that bullet. I really wanted to build a portfolio project with MAUI to have something cross-platform but was already wary because of Microsoft's non-stop parade of overlapping, half working, UI frameworks. I experimented with MAUI for a couple of days but kept running into issues on the most basic of things, only to find out it was a known issue that had been left unaddressed for an extended period of time.
From the outside, it seems crazy that a multi-trillion dollar company would put out a product this broken and leave it that way for a long time but anyone familiar with the internal workings of Microsoft sees this as another case of a team having lost some insider battle and banished to nether reaches of the company, starved of anything more than token resources, to slowly decay to death.
We're a dotnet shop and we're looking to rewrite our iOS and Android apps in a cross platform framework. On paper MAUI seems like the perfect fit but reading through the discussion and issues in GitHub it's nearly guaranteed this will go the way of all MS's UI products. The number of unresolved issues for fairly basic functionality and the number of developers voicing their PTSD from MAUI related development has made us steer clear.
Does anyone have the inside scoop on what happened to Microsoft? They were never great in terms of software development, but it seems like they have become completely unable to develop products. Win32 lasted for decades, but I’ve lost count of how many successor frameworks have come and gone. Products like OneNote or Outlook get replaced with new versions that have a fraction of the features and are walruses of bloat. (It’s been years, and “New” Outlook still pops you over to the web to look at your todos.) “New” Teams can’t even keep up with scrolling a large directory listing, when mapping the same share in Windows Explorer results in instant display. This is shit smart high schoolers could do and did back in the day. Microsoft seems to have fallen off a cliff. What happened?
I tried to use the MSTeams API in the last year. It (the example GitHub repo) was obviously basically abandoned by MS except for some third world subcontractors that I'm sure a PM at Microsoft was managing while she managed her 401k and coasting into retirement. What a mess.
Don't get me started on MS and UX libraries everything you need to know about microsoft and the state of UX is is that they are trying to implement a complete darkmode for windows since 2015 and are still failing at it.
Technically, it got moved into being a discussion, as the underlying bug (the thing that's been broken for 1.5 years) actually still has its original issue open, so this the actual bug report of this issue is basically a dupe.
If I got an issue that started with "DO NOT CLOSE THIS ISSUE BECAUSE YOU THINK IT DOEN'T MEET THE CRITERIA OF A VALID ISSUE!" I would be pretty inclined to close it without reading further.
What? A multibilion corporation does not listen to user feedback on GitHub? That's so crazy and unusual. Take some lessons from Google here, when users complained on quality of software and bugs in it, Google just archived OSS repos and moved development to private repo. Opensource and issues on repos are close to worthless (sometimes somebody else in comments will find a solution or work on a fork, but that's it), might as well be not available at all.
The Chrome team must be an exception then, my bug reports there usually get prompt feedback, and when those were actual problems they also get fixed in time (sometimes it takes months, but that's typical for large projects). Apple on the other hand is just a black hole for bug reports, you never hear anything back.
It's like the Chrome team realizes it actually has users. Many other software projects I've witnessed seem to think they just throw their stuff into the void and nobody will care.
Microsoft uses Google's framework for their own applications: Electron.
Yes, you heard me right. Microsoft, a nearly 3 trillion dollar company, uses the framework of a competitor for their own desktop applications.
Teams: Electron.
Visual Studio Code: Electron.
Azure Data Studio: Electron.
Now, let's make a similar list for Microsoft MAUI apps!
Umm... err... hmm...