[jiggawatts]

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!

Umm... err... hmm...

[frankjr]

> 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.

[pas]

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.

[tpae]

Even github is full of bugs these days. I hate Microsoft products

[npteljes]

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.

[lawgimenez]

Not long ago someone from Maui posted here about the “momentum” within Microsoft.

[npteljes]

I can believe that. I mean, the momentum even. Only time will tell if it really comes to fruition.

[spacechild1]

Electron has been originally developed by GitHub and is now maintained by the OpenJS Foundation. It is not a "Google framework".

[nvm0n2]

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.

[gloosx]

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]

[1] https://chromium.googlesource.com/chromium/src/+/HEAD/AUTHOR...

[nvm0n2]

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.

[gloosx]

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.

[charrondev]

With edge being switched to Chromium some years ago I would assume Microsoft also has a quite a few engineers working full time on it.

[torginus]

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.

It never made it into their core offerings.

[ecmascript]

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.

[cristeigabriel]

> Teams: Electron.

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.

[physPop]

The new teams is react + webview see:

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.

[deafpolygon]

It may be that MAUI wasn't mature enough yet at the time they started working on it.

[debugnik]

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.

[zigzag312]

Refactored Xamarin.Forms with breaking changes.

[rayiner]

And the performance is still crap. What does that say about MAUI?

[cristeigabriel]

Thanks for correcting me!

[ChrisMarshallNY]

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.

[0] https://en.wikipedia.org/wiki/Microsoft_Visual_SourceSafe

[christophilus]

Is git worktree close enough? In the past, I’ve used it roughly the way you describe.

[ChrisMarshallNY]

I don't think I've tried that.

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.

[0] https://git-scm.com/docs/git-worktree

[malodyets]

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.

https://svnbook.red-bean.com/en/1.7/svn.advanced.externals.h...

[denton-scratch]

Externals is a footgun that can cause nasty injuries. I like Svn, but I won't be using Externals again.

[fanf2]

The main criticism I heard of Visual SourceSafe was that if your repository got bigger than 2GB it would be irretrievably corrupted.

I understand it used the same storage engine as a number of other Microsoft products, including Exchange, which had the same bug.

[ChrisMarshallNY]

It was awful.

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.

[stevekemp]

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.

[Razengan]

> 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.

[gloosx]

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.

[mathverse]

This. I believe OneDrive on macOS uses QT.

[Zetobal]

It does but here is the kicker... it also uses QT on Windows.

[ukFxqnLa2sBSBf6]

Hey genius, VS Code was released in 2015 and MAUI was released in 2022. Do you see the problem?

[ludwik]

Can you point to a source for Electron being a Google framework? As far as I know, the framework has been created at Github (now owned by Microsoft).

Google has created a UI framework for building mobile, desktop and web applications - but it's Flutter, not Electron.

[legulere]

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.

[MyFirstSass]

This is bizarre to me.

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.

[icegreentea2]

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.

[nicoburns]

I believe some MS apps are also using react native these days (and MS maintains the desktop ports of react native (both windows and macOS))

[hu3]

Angular is prime example.

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.

[ecshafer]

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.

[wg0]

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.

[zigzag312]

> Flutter, Qt, Swing or other immediate UI libraries

You mean retained mode UI libraries?