The problem is that they just could not commit to anything for more than 2 years after Win32. They had something reasonably good in WinRT. They should have stuck to that. But Nadella came in, said Azure Cloud is the future and abandoned the Windows platform.
Microsoft hasn't had a coherent GUI strategy since Petzold
101–110 of 604 posts
Re: Microsoft hasn't had a coherent GUI strategy since Petzold
#102Re: Microsoft hasn't had a coherent GUI strategy since Petzold
#103Steven Sinofsky wrote this piece a couple of weeks ago about the same topic: https://x.com/stevesi/status/2036921223150440542
Re: Microsoft hasn't had a coherent GUI strategy since Petzold
#104Nobody really has. Apple comes the closest but they keep rug pulling it in weird ways. Windows and Mac in the 90s had very consistent GUIs with such consistency in things like keyboard shortcuts that apps could easily be learned. The term “intuitive” was king in the realm of UI design. Then the web hit and all that died.
Not nobody. KDE has a functional and consistent GUI.
If you really enjoy worse Windows XP UX with hamburger menus in recent versions then by all means go ahead, it does function.
Re: Microsoft hasn't had a coherent GUI strategy since Petzold
#105That AI image at the end was more amusing than informative. Almost lost it at "Win15" and "Chrondum + frade.js".
Re: Microsoft hasn't had a coherent GUI strategy since Petzold
#106Steven Sinofsky wrote this piece a couple of weeks ago about the same topic: https://x.com/stevesi/status/2036921223150440542
It's very amusing to see Sinofsky of all people all but dumping on .NET and (still?!) not understanding why developers so proactively jumped ship from Win32 & MFC hell to WinForms. Or why the HTML/JS app model in Win8 never really took off. I was in DevDiv during his great WinRT push and the overall feeling I remember was that the guys in Windows had zero clue as to what the devs actually wanted, but were hell bent o…
Re: Microsoft hasn't had a coherent GUI strategy since Petzold
#107Earlier quoted context omitted.
Your post is touching on a key question: why write a Windows-specific app? I'm a developer who has built and published several apps. I want the biggest possible audience for those apps. Why would I limit those apps to Windows? (Or even to any single platform/OS?) Web apps work everywhere. The web has grown increasingly powerful and capable. Why would I invest in a technology that can only run on a single OS? Doesn't…
I used to get hung up on this native vs web thing. But when it comes down to it, it's just one renderer or another unless you're actually drawing the controls yourself pixel by pixel. The sticking point is following the system style / theme. But all the popular desktop OSs seem to have deviated on this so much themselves I'm not sure how important this is.
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.
Re: Microsoft hasn't had a coherent GUI strategy since Petzold
#108The problem is that they just could not commit to anything for more than 2 years after Win32. They had something reasonably good in WinRT. They should have stuck to that. But Nadella came in, said Azure Cloud is the future and abandoned the Windows platform.
WinRT was technologically terrible (which immediately flows from "no one at Microsoft was actually using it to make anything useful"). But that wasn't even what sunk it - the whole requirements around "of course your WinRT app is going to be in the Microsoft Store^TM its the future" did that. The fucking store is a joke, and those requirements existed solely to boost a bunch of idiots internal careers.
I still don't understand why the windows store search sucked so badly. It isn't like they had billions of apps. So why did it suck?
Re: Microsoft hasn't had a coherent GUI strategy since Petzold
#109The churn would have been much worse if Microsoft was rolling out successful GUI framework after GUI framework. As it is you can still write a Win32 app if that pleases you, or still write .NET (and damn that runtime download!) Microsoft has bought into ‘make a web app’ since 1988, they introduced AJAX, they got flexbox and grid into CSS and numerous HTML 5 features to support application UIs. They ‘frikin bought npm…
Your post is touching on a key question: why write a Windows-specific app? I'm a developer who has built and published several apps. I want the biggest possible audience for those apps. Why would I limit those apps to Windows? (Or even to any single platform/OS?) Web apps work everywhere. The web has grown increasingly powerful and capable. Why would I invest in a technology that can only run on a single OS? Doesn't…
For me, I see these following advantages:
- Performance; Native & compiled is king.
- Ram usage; Kilobytes vs Mega(giga?)bytes.
- UI control which integrates with the rest of the OS (and updates when the underlying OS tweaks the UI)
From a business standpoint, I get your point that these points don't really matter. Users have shown to not care in the slightest at the bloat in programs.
However for code I write in my spare time, I would much rather write my native Linux program in compiled code than to ship a subpar experience to the few who will interact with it.
Re: Microsoft hasn't had a coherent GUI strategy since Petzold
#110What's still missing is deeper integration with native OS concepts and programming languages other than JS. Frameworks like Electron are a step in that direction but they come with notable drawbacks. Applications often struggle with things that should feel natural like managing multiple OS-level windows.
Another PITA: Electron apps repeatedly bundle large portions of Chromium, leading to unnecessary overhead. Those duplicated modules lead to bloated RAM usage: every app has its own Chromium copy and OS must keep all that zoo in RAM without a possibility of reusing the otherwise shareable parts.