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...
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.
That said, OP's point is crystal clear, these silly new platform projects are the busywork of vestigial orgs.
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.
It never made it into their core offerings.
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.
https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
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.
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.
[0] https://en.wikipedia.org/wiki/Microsoft_Visual_SourceSafe
https://svnbook.red-bean.com/en/1.7/svn.advanced.externals.h...
I understand it used the same storage engine as a number of other Microsoft products, including Exchange, which had the same bug.
!! _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.
Google has created a UI framework for building mobile, desktop and web applications - but it's Flutter, not Electron.
What applications are they actually using the framework for?
Is it because it's easier to make cross platform?
Reminds a bit of when i used Angular back in the day and it seemed Google of all people didn't use it for any of their many web services.
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.
From my consulting experience, Angular (Google tech), is most used today along with .NET backends (Microsoft tech).
I don't think I ever saw a client using Angular + Go, for example.
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.
You mean retained mode UI libraries?
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.
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#.
[1] https://github.com/dotnet/maui/issues/8926#issuecomment-1563...
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.
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
more of the same https://github.com/dotnet/maui/discussions/17917 https://github.com/dotnet/maui/discussions/15203
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.
Edit: Clarified a few statements.
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.
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?
* 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.
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!
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.
Examples: - AWS is in the critical path for Amazon
- .Net is in the critical path for MS
If you chose a software or service that is not in the critical path, the jokes are on you.
Some of the Microsoft teams don't listen to user feedback.
We use Azure DevOps, feedback from years ago for basic features still not developed.
You should start your migration to GitHub actions.
https://ideas.fabric.microsoft.com/ideas/idea/?ideaid=020078...
Which is just a parser feature.
Then you can switch easier, if need be.
I think Microsoft has given up on facilitating application development beyond VS and C#.
Just use the web platform unless you really, really need to do something specific which cannot be done as a web app.
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]
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.
Sure, they build products, but only to the point of being infuratingly unreliable.
I was hopeful, but not fully convinced that Microsoft had turned around. Turns out that the naysayers were, of course, completely right.
No touching of Microsoft frameworks. Dotnet may look good, but this will happen to it too.
I mean, this is still an awful look for MAUI.
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.
Microsoft is in the wrong here for selling this as the future and not dedicating the resources necessary to fulfill that promise.
https://devblogs.microsoft.com/dotnet/announcing-dotnet-maui...
Also you’re implying that MAUI does not have serious problems, which is not true the case.
It’s good to bring this to people’s attention so that others do not make the same mistake choosing MAUI as this guy.
The MAUI team should reflect as well about the reasons people need to stay away from their product.
Your “everything is fine, this guy is just overreacting” makes me think you haven’t worked much with MAUI.
Easely like 100x the efficiency fixing small bugs.
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.
Yes, we need to be more lenient on Microsoft. They're a tiny little startup after all, they barely have 10 employees and three of them are cleaners.
Thanks for the heads-up.
[UPDATE] Ah. Now I remember [0]
It does roughly that, but it still insists on bringing in the entire repo (as does all Git).
The thing that SS did, was allow you to create a "chimera" workspace, composed of just tiny parts of other workspaces.
It was a great way to share sample and SDK stuff, without, for example, sending over a ton of testing code.
Many of my repos have more testing code than implementation code; not to mention a ton of documentation.
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.
"Yes the soup is cold, but we no longer give people botulism with the salads surely that counts for something"
It was a straight file-based system; run entirely from the client. No server component.
You mounted a server drive onto your desktop, pointed VSS at it, and then fixed a four-course meal, while it synced.
No server. For a shared VSS.
I’m not surprised MS didn’t use it.
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.
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
There is no direct quality/polishness in there.
Edit: formatting
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]
[1] https://chromium.googlesource.com/chromium/src/+/HEAD/AUTHOR...
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.
Single or multiplatform? Which OS?
Will there also be a mobile or web version of an app? Or embedded?
How well does it need to integrate with target platform? How native it must feel? Does it access to native platform features?
Does it need to be lightweight?
Does it need very low latency? Is performance critical?
Does it need many custom widgets or none?
Does it need to have quality implementation of any specific widgets available (like charts, maps etc.)? Big widgets ecosystem?
Does it need heavy widget trees?
Does UI need to be customizable by users?
How important is accessibility?
Programming language preferences and limitations?
How important is developer productivity?
Can framework be proprietary or non-free?
Is it maybe just to learn UI development?
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.
And obviously, grain of salt, third-hand knowledge, etc.