Judging by the modern Windows apps, that seems true as most of them (ClipChamp, Weather, News, etc) are just web apps with an Edge wrapper similar to Electron apps.
I'd get it if they were meant to be cross platform apps, but they're not. Crazy they couldn't have bothered to write native windows apps in .NET/C# for something that's obviously meant to be Windows exclusive. The community writes way better Windows apps (Sumatra, Notepad++, etc) than Microsoft does internally.
Microsoft has no cohesive product vision for the OS and just seems to let various groups slap random low quality shit to the OS, based on some internal power struggles their managers win in the org I assume. It's ironic that low quality slop like those and ads ship by default with the OS, but the truly useful and high quality utilities they write like PowerToys, do not.
They lost the plot on their core audience after Windows 7 and sloppy implementations of "AI" like Copilot+ and Recall won't bring them back, on the contrary, it convinces people to GTFO to Linux ASAP.
They do, there is just no top-down initiative that says "use WinUI with C# or lose your job, make sure to throw out React Native and WebView2 by the end of this quarter". That would at least cover Windows. Or they could force everyone adopt MAUI internally instead, despite its flaws (if you dogfood something heavily, bugs get fixed fast).
I find it funny that, unlike OneDrive, iCloud desktop client uses WinUI.
But I'm not holding my breath and think that whoever could make this reality was pushed out of the relevant teams or the org as a whole by the time W11 shipped - just look how they killed great OneNote UWP variant. Salvaging the situation would be an improbable miracle.
> At this time, there are two generations of WinUI: WinUI 2 for UWP and WinUI in the Windows App SDK (WinUI 3). While both can be used in production-ready apps on Windows 10 and later, each have different development targets.
In the Microsoft land it's always utterly confusing to get started. You are always left guessing what choice to make.
>In the Microsoft land it's always utterly confusing to get started. You are always left guessing what choice to make.
Not it isn't. What you're pointing out is the PRO of Windows, not a CON. It's why backwards compatibility works so well. If you have a super old app you're still developing, you can keep using that old UI stack, no need to rewrite it on a newer one just for ti to be compatible with the latest Windows release.
I feel like most people complainant about the different UI stacks supported by Windows, are not Windows developers but just enjoy pointing it out as if it bothers them somehow through sheer existence even though they never wrote any Windows apps.
The Windows developers community are pissed off with how badly WinRT was managed since Windows 8.
There is seldom anyone of us that went through that, and will advise anyone to use WinUI 3.0, unless they themselves have a sunken cost into UWP, and need a way out.
Quite easy to find out in the endless discussions on the related Github repos.
Because like many in the Windows developer community, Microsoft has ripped us off with all the mess they have made with WinRT since 2012, multiple rewrites, broken tooling, dropped features.
And worse of all, in the end, those of us doing WinRT advocacy, were the ones answering for Microsoft's missteps in customer meetings.
Too many hard feelings to let it go just like that.
In this regard, as already discussed before, it what saddens me that Apple and Google are more willing to double down on their UI stacks, Android and iDevices, than Microsoft.
If one of them was at the steering wheel of Longhorn, it would most likely been shipped with its .NET based architecture, improved in later releases, and everyone that wasn't into it, could have looked for a job elsewhere.
I suspect they forgot the value of internal training on their own platform’s tech and they just hire folks from outside and let them run wild, and all they know how to do is React, so that’s basically what we get.
>It's ironic that low quality slop like those and ads ship by default with the OS... it convinces people to GTFO to Linux ASAP.
It certainly convinced me. Steam Proton runs pretty much all the games I enjoy (mainly indies), and I can quarantine Windows in a VM for MS Office, as well as keep a full Windows installation on a separate disk if I really need it (rarely).
The crap that's made its way into mainline Windows makes me feel like my computer isn't serving me anymore.
My understanding is that it takes orders of magnitude longer to develop native Windows applications than it does to develop webapps. I think that your suspicion is right and that some PM along the way was able to make the business case that we could ship 75% of the product using 10% of the engineering resources.
It's a drag, though, because as everyone will immediately see, having a shortcut on your keyboard to open glorified GPT-4 isn't really a killer feature.
Well that's just the thing, I would assume there are significantly more web developers in the market than developers with experience writing Windows apps of a high enough quality to be shipped in the OS.
You also need to follow all the Windows guidelines pattern here.... The only choice for this for a while was WinUI/UWP. And there isn't a lot of WinUI/UWP devs.
My understanding is that it takes orders of magnitude longer to develop native Windows applications than it does to develop webapps.
If you know what you are doing, not at all. That being said the technologies are quite different and not all skills are transferrable. If you're an experienced web developer, then transferring to writing Windows apps takes a bit of getting used to. Once you've wrapped your head around C#, Visual Studio and WPF or WinUI3, and embraced the Window Way, it's actually a quite productive environment.
What I suspect we might be seeing is that Windows has so thoroughly lost the developer mindshare battle, that not even Microsoft can find experienced Windows devs to hire, and most of their new developers have a web first programming background and have never used any of the Windows GUI frameworks.
That's essentially I'm suggesting. I totally agree that in a world where one's team is made up of highly skilled C# developers with lots of experience writing Windows apps, I'm sure productivity is fantastic.
In the world which 99% of software teams live in though, the former skillset is far, far rarer than the React/node/Vue etc. toolkit which is a dime a dozen these days. If a fresh team wants to from 0 to functioning product, I still stand by that they'll get it out the door _much_ faster using some agreed upon webstack than they would doing it the Windows Way. Hence the "orders of magnitude" phrasing which others are having trouble with.
For someone with no training on Windows tech, using no helper tools, but who has lots of experience using web tech, maybe. But not only is that not true with the right skills and tools, but these webapps don’t even have feature parity. If they can’t do everything a native app can do then it’s not even a comparison.
> takes orders of magnitude longer to develop native Windows applications than it does to develop webapps.
That seems extremely far-fetched to me. If it's for economic reasons, I think it's more likely related to availability of developers with webapp experience vs native experience.
Which they could easily solve if they invested in training new hires on their own internal tech, but I suspect that’s long been cut to the bone. So if you can only rely on what skills people have when they join, you’re going to dilute any proprietary tech you have.
It's precisely for economic reasons, hiring a qualified team being the long tail here. I assure you guys that it's much, much easier finding a team of decent web devs than a team of decent Windows devs. Is that really so far-fetched?
I assume you're right, but it's still quite absurd. Apple has recently released applications written natively in WinUI (iCloud for Windows). So Apple can more easily hire/train WinUI developers than Microsoft?
I'd accept the "difficulty" excuse from a company like Walmart. But we're talking about a (relatively) small number of built-in mini applications here, inside a tech-specialised company that created, maintains and presumably promotes this native framework.
Can't help but see this as anything other than "The team working on it doesn't know how to code native applications on our OS"