Sure it is a hassle to get notifications working, but my take on that for years as a desktop user was "I need another source of spam about as much as I need to get raped". For years I had bottom of the line Android Tracfones and wondered "how is it people get so excited about apps?" because they just didn't work but once I got an iPhone I started to appreciate that the McDonald's app would send me a notification when my food was ready. Recently it was pointed out to me that the application behind these cards

https://mastodon.social/@UP8/116086491667959840

really would benefit from notifications ("your photos are ready!") and I am looking at the hurdles I can jump through and it looks possible but weird. Like why would I want people to install my app on the homescreen where it will get lost on page after page of twisty little app icons that all look alike?

Then there is that PWA boondoggle, there is another app in that system that I can use to register those cards and it is a clear case where I might want to do it outside of cell coverage (say I was in the woods) save a form submission and upload when I get back in range.

What can I say? That service worker system is insane, something like Kubernetes that only Google could subject us to. I mean, Google could have worked out the math for synchronizing a local database to a remote database, by then the Lotus Notes patents were mostly expired, we could have gotten something good. Or Google could have added an API to control the behavior of the browser cache. Instead we got something half baked and barely reliable and then Apple went out and made something a little bit worse. Had it been a good standard to begin with the outcome could have been entirely different.

I currently have open Chrome, Spotify, Discord, Aseprite, and Zed. All of them look completely different, and that's actively helpful for me, the user.

It's nice to follow the system's light/dark setting, and obviously the behavior of basic UI controls should be unsurprising, but beyond that there's no point in "consistency".

for the dedicated more native stuff dioxus is kinda cool if you don't want a web stack in the mix.

i'm enjoying golang and wails though paired with whatever front end i want, all apps i've made perform execellent on windows. bottom line = yeah i can't really think of a scenario where i personally would ever write an app for windows specifically.

i, like you, used to get hung up on native vs web framework. i'd encourage you to give it a go, possible you cede that mayhaps the native thing isn't as important as you thought.

And he probably wonders why it is never "the year of the Linux desktop" but hey it is OK because Red Hat Linux is something enterprises subject their users to and if it had the slightest bit of flair customers would complain.

So when I hear GTK I think Nein Danke!

In general Linux has the kind of fanbois problem that MacOS had maybe 10 years ago. There are so many things that still "just don't work" after years and they never get fixed because you can live without them. For instance I can tell you how to install some package like

   sudo apt-get install mypackage

[1] and you still might misunderstand it and need intensive tech support

I have one application at work that loads a table with 40,000 rows into a data grid that works really well on Chrome and lags on Firefox, that's the one case where the performance difference matters.

This year I've been interested in biosignals applications that read data with the Web Bluetooth API and Web Serial API which are ordinarily Chrome-only. I was about to get one of my junk Android tablets out of mothballs when I found there is Bluefy for iOS which supports the Bluetooth API so I have no problem going to labs where they have a really klunky HRV system based on a PC and show them something sleek on my iPad and in 20 minutes i can demonstrate to you, with your own physiology, everything you actually need to know out of a big review paper on HRV.

Slack is, in fact, one of the worst offenders. It is so incredibly sluggish. And it doesn't need to be, when I compare it to the speed (and memory consumption) of Pidgin with the Slack plugin.

That is, uh, controversial.

Along both "alleged replacement" and "alleged superiority" axes.

That was such an amazing mission statement. It was a real measurable goal, and progress towards it was quantifiable. And Microsoft actually did it! That mission statement drove actual strategies (lower costs, don't complete with Apple on the high end, force OEMs to compete against each other on price, etc) that resulted in its ultimate fulfillment.

Gates did this with Windows, Office, XBox among other things. Ballmer failed to do this this with Windows Phone. Nadella did it with Azure, but he needs to do it once again with AI. You can see that he's pushing hard with Copilots everywhere, what's missing is a manager that has a coherent vision of what AI at MS should look like. ScottGu is in charge of both Azure and AI at MS, but I don't know if he can deliver.

He maybe never had a strategy for Windows but he wasn't hired to have a strategy for Windows.

The UI in Rowland's demo at 32min is feeling a little DearImGui / Reaper-ish, kinda bland while also being non-native. But I've seen all the UIs that Arturia & everyone else makes with JUCE, even what Valhalla does with it with their NASA inspired interfaces, so it can clearly make amazing stuff.

I can't believe we're now looking to PACE of all companies to help indie devs. I hated iLok for so long even though I have two iLok dongles now ;)

But Qt has the bonus of also running on HaikuOS, and I've definitely seen more business apps in Qt (pretty sure 010 Editor is Qt).

Linux is a mess, but at least it's unapologetically so.

1) VB7 (VB.NET) entirely split the VB developer community.

2) VB6 IDE has not worked well and is entirely unsupported in every Windows after XP. It's generally recommend to build VB6 apps in an XP VM and XP being out of security support it's now a huge "Use at your own risk" and "Do your best to isolate the VM from ever having an internet connection". (Not to mention that installers like Install Shield that still understand VB6' super messy version of COM are generally also out of support and security support.)

It was alleged that Microsoft almost dropped the runtime components for VB6 in Windows 11. It starts to feel like only a matter of time before they do.

It's just that it's a piece of tech from back when Microsoft corporate dominance on the desktop was at its peak, and many large companies bought into the then-current tech stack, including VB6. So now Microsoft is stuck maintaining it because those are the customers that bring consistent revenue.

At the risk of getting my Microsoft history wrong, I'm fairly sure that Steven Sinofsky wasn't working on Windows or even MFC (i.e. what he did as one of you guys) in .NET's early days of 1999-2003. He was leading Office at that time. Office of that era was transitioning from the Windows XP look that still persists in Windows Forms to the early Ribbon, and was then (as now?) using very custom GUI code that didn't correspond to any specific higher-level Windows app framework.

Mac OS Office apps had just separated their codebase again from Windows apps after being unified in the mid-90s to get to feature parity (which annoyed Mac users who felt they now had non-native-feeling apps that were slow and bloated), and the "Office framework" was still quite distinct from any single-platform Windows app as a result of that.

So if Sinofsky did not understand why people went from USER/GDI to WinForms, that may just have been the fact that nobody working for him had felt the need to make that transition.

The fact that UWP XAML was its own new thing and not a extension of an existing Microsoft GUI app framework like WPF was not necessarily a "we hate managed code" thing, or even a "we hate those guys who invented managed code and want to screw them because we're Windows" thing. After all, .NET managed code had equal access to UWP through the .NET WinRT projection!

And to me at least (I didn't work on UI-facing stuff in Win8), it was absolutely conceivable that UWP could have just delivered Windows Phone 7 Silverlight's version of XAML to native code apps, with a thin adaptation layer to let even unmodified WP7 app binaries run on the desktop Windows .NET Framework with the WinRT projection and to allow slightly modified WP7 apps to look good in landscape mode on both Windows 8 and WP8. If we had done that instead of making UWP XAML its own thing, and if we had integrated the Windows Store with the Windows Phone Marketplace from the beginning so that Windows and Windows Phone apps could be sold as variants of each other through a single Store/Marketplace product entry on Windows 8 GA day, then I think we could have brought a lot of people forward who were already making good WP7 apps, and the Store wouldn't have been so empty.

Furthermore, IIRC much of the original UWP XAML implementation was done by the original people who built WPF and Silverlight the first time, and they would have known what they were doing in separating UWP XAML from Phone Silverlight. That they didn't go in the direction of extending Phone Silverlight was not necessarily shortsightedness on the part of provincial Windows people. Maybe they thought Phone Silverlight actually demonstrated fundamental limitations of WPF or Silverlight XAML or the Silverlight "coreCLR", or they wanted to make breaking changes as lessons learned from Phone Silverlight, which was put together about as hurriedly. (Windows Mobile 6 -> Windows Phone 7 first previews = 1.5 years; Windows 7 -> Windows 8 first previews = 1.5-2 years, tending toward 1.5 years if you account for the frantic re-planning after iPad came out in early 2010.)

It's important to remember the specific reasons why Windows RT 8 chose to not support third-party desktop apps. The most important aspect of "iPad compete" that we wanted on Windows for ARM was not "all app UXes look and work well on touchscreen tablets" but "you can't ship malware, not even by rebuilding your x86 malware from source." Thus, every 3rd party app on Windows RT would have to live in the AppContainer sandbox that UWP apps are in by default, and the requirement that you ship through the artist formerly known as the Windows Store would be a second line of defense against malicious apps. And with the forced-enabled Secure Boot, subverting the user-mode controls by secretly installing a bootkit would be hard even with physical access to the PC.

Even within the Microsoft world only, Windows Phone 7 had proven the success of this approach of locked-down apps only available through an app store that checked apps on submission and afterward for security. It was not unreasonable to think that similar lessons might also benefit users of "big" Windows, which is why Windows 10 and 11 have the opt-out "S mode" which defaults to the Windows RT restrictions.

I do wish though that Windows 8 had learned different lessons from WP7 (about which more in another point).

fair. but that struck me as strange even then. if anything, visual studio should have adopted the all-lowercase typography of the original metro-style design language from zune and windows phone 7, not AN ALL-UPPERCASE ONE.

Perhaps that was just another way that Windows 8 Metro-style apps' design and developer platform was like Windows Phone 7's Metro style, yet different in seemingly gratuitous ways. That is something I would attribute to internal Microsoft politics. Steven Sinofsky and Terry Myerson (leader of Windows Phone at that time) never really got along, and in the Microsoft philosophy of that era where engineering divisions were completely locked down from each other by default, that rivalry would have discouraged what little natural collaboration would have happened anyway.

I think the real mistake there was not so much that a particular projection of the Windows Runtime was stopped, but the more general idea that developers should be forced to consume what became known as the Universal Windows Platform or author custom WinRT components through only Microsoft-made WinRT projections.

In the name of winning over new or inexperienced Windows developers with "simpler, safer" projections, we in the Windows division almost completely failed for about 5 years to document or even explicitly say that WinRT was essentially just "COM: The Good Parts, Version 2012". (Martyn Lovell's Build talks on the origin of WinRT were a notable exception to this.) This discouraged people from using their existing COM skills to develop Metro-style/UWP apps or to gradually adopt features from UWP APIs that were accessible to them in their existing desktop apps. Other people have written that "WinRT=COM" thinking is actually a bad idea because it forces people to deal with COM and its more annoying ideas (separate IDL etc.); I disagree because we should have reached out to people who live in COM world to get a ready developer base.

That mistake was a key part of the still larger mistake you touched on of trying to make the UWP and desktop worlds 2 completely different developer platforms that happen to co-exist on the same desktop edition of the Windows OS. That was the key "we didn't listen to developers" mistake that set up UWP for its market failure. Another example: Even today, you can't adopt the battery-friendly UWP app lifecycle using Windows App SDK, which is supposed to be the UWP successor for desktop app developers. So much for WinAppSDK (or indeed UWP/Metro-style apps in Win8) enabling a true no-compromise user experience.

It took real tours-de-force like Kenny Kerr building C++/WinRT and blogging about it, Raymond Chen blogging about using WinRT APIs through the unprojected "ABI" interfaces, or the VideoLAN organization building a Win8/Win10 UWP version of VLC in C, to get the word out that the UWP world wasn't some alien thing with dark magic that only Microsoft wizards had full access to. And it doesn't help that the wizards really do have a few special powers that they jealously guard even now.

With WinForms, we actually got something that was convenient without shackling you. And the whole cross-language story was great, too, especially around .NET 2.0 - with C++/CLI you could very easily wrap any random native code C or C++ library for consumption from .NET, with end-to-end integration in the build system, IDE etc.

That was at least in part due to the aforementioned obsession with iPad and generally mobile. One thing that Sinofsky is not wrong about in his post is that the classic Win32 app model is not conductive to good battery life - there's very little there to properly handle things like automatic background suspension or low-power push notifications. WinRT was designed with that in mind, but that would make no difference if the apps would just ignore it, hence the heavy-handed push for WinRT apps only (AFAIR it wasn't restricted to Store, although you had to jump through some "developer mode" hoops to deploy apps directly).