What I find must puzzling is that everyone seems to just be violating basic rules that had been in place for ages.
Things like:
- If you can't respond to a UI event wait until you can
- Menus should be tree structures
- Pressing alt should underline the hotkeys you need to access anything clickable
As well as just basic responsiveness or predictability. A 2000 era windows application may not have been pretty, and may well have several different styles all imitated from office, but at least I knew what everything did and when it was slow at least it did what I expected.
This meant I could start the computer, log in, potentially start and use several applications and only then turn on the screen. Nowadays that has no chance of working because even to log in I need to press enter or click some button (which one depends on how I logged in previously, maybe) before I can even start typing and doing so eats a random amount of keystrokes while the damn log in screen loads to do its one damn job.
It's because we went from the Desktop environment, where rules were well-documented and standardized, to the Web/Mobile environment, where rules had to be reinvented and, for the most part, were not.
Over the past year I've started thinking a lot more about design and UI work, and I think it's basically impossible to design things, or create design systems, that appeal broadly to different types of users in a cross-platform way.
I personally love dense UIs and have no expectation of doing certain kinds of work on a phone or low-powered device like a chromebook, phone, or bottom-barrel laptop. But if you're a company trying to sell products to a broad user base, you want to try to design in a way that works for those kinds of users because they still might be end-users of your product. And there's a good chance that those platforms may be where someone first evaluates your product (eg from a link shared and accessed on a mobile device) even for the users who do plan on using more powerful desktop devices to do their work.
So instead we get these information poor, incoherent (because it turns out proper cross-platform, cross-user design is much more difficult than just getting something that works cross-platform for all users on its surface) interfaces. I guess I'm writing this just to add, web/mobile have complicated things partially because more than just requiring their own distinct patterns, they each represent a distinct medium that products try to target with the same kind of design. But because they're different mediums, it's like trying to square a circle.
We've ended up in a world where power users have been forgotten. Not out of malice, but out of a misguided aim to reduce complexity and achieve consistency with the web.
I would argue that desktop is the platform for power users, and its future depends on them. The keyboard shortcuts, the micro-interactions, the window management -- this stuff is all important when you're using a system for 8+ hours per day.
Yet we risk desktop experiences becoming less useful due to the UI becoming "dumber" as we keep shoehorning websites onto the desktop. Website UI is dumb. It's mouse driven, keyboard is an afterthought. There's no consistency, and you have to re-invent the wheel every time to get the details right (almost never happens).
>We've ended up in a world where power users have been forgotten.
I think its more like the OS vendors have stopped being operating system vendors, and are now - instead - vendors of eyeballs to advertisers.
The less the user is GUI'ing, the more they are just watching, placid, whatever else is on their screen.
For native apps to survive, they need to not be platform-specific - i.e. web apps, which require a browser and all its responsibilities - but rather cross-platform, reliable, predictable on all platforms - i.e. dissuaded from using native, but rather bespoke, UI frameworks.
This is attainable and there are many great examples of apps which are in fact, old wheels not re-invented, which still work for their particular user market.
I have the most respect for apps I can use on MacOS, Windows, and Linux - with the same hotkey/user experience on all platforms, equitably - and the least respect for apps which 'only run on one of them', since that is of course nonsense in this day and age.
The cognitive load of doing a web app that can do all the things a native app can do, is equivalent to the load required to build a cross-platform app using native frameworks, so ..
Mozilla removed a lot of power-user features and customization from Firefox claiming that their telemetry showed that few users used them. That's the reality now, nobody wants to develop and maintain things for the 1%.
> We've ended up in a world where power users have been forgotten. Not out of malice, but out of a misguided aim to reduce complexity and achieve consistency with the web.
Power users are less susceptible to suggestion and therefore less profitable. They have largely moved to OSes that do not interfere with their wishes, allowing them to make their own choices about what they can or can't do/run (Eg. Linux).
This resonates deeply. I build native macOS apps in Swift/AppKit and the difference in keyboard-first design between native and web is night and day.
On macOS, if you use standard NSResponder chain and menu items properly, you get Cmd+Z undo, text field navigation, menu bar keyboard access, and accessibility basically for free. The framework was designed around the assumption that users would become experts.
Web apps actively fight this. Every Electron app I use has broken Cmd+` (window cycling), inconsistent text selection behavior, and that characteristic 50-100ms input lag that you stop noticing until you switch back to a native app and remember what "responsive" feels like.
The sad irony is that making a power-user-friendly desktop app is actually less work if you go native, because the frameworks already handle the hard parts. Going web means you have to manually reimplement every platform convention, and almost nobody does.
I know this isn't really your main point but I don't think they've been trying to reduce complexity but rather increasing ease-of-use for the end-user*. Those things are often completely at odds with each other in software as I'm sure you know.
*well, that seems to have been their goal in the past; nowadays it just seems like they've been trying to funnel windows users to their other products and forcing copilot into everything.
If you become a power user you realize that nothing matches the power of the command line. And at that point you also realize that are better OSes that allow you to fully explode the true computing power that is terribly limited and constrained by a GUI.
> We've ended up in a world where power users have been forgotten.
I think the world changed. "Power users" in the traditional sense use Linux and BSD now. Microsoft and Apple dropped them when they realized how lucrative it would be to dumb things down and make computers more like cable TV.
Well, Alt+Tab in Windows is supposed to switch windows. That's unless you're in Microsoft Edge where obviously, it switches tabs. Inconsistent and annoying.
Android and Chrome worked like this for a hot minute too. I assumed the idea was to promote webapps to look like they're first-class citizens, but in practice it's just bizarre and confusing UX.
Browser tabs are the fault here and browsers are trying to be OS environment, so Alt+Tab is useful for major task switching. I agree it's inconsistent and annoying, but I like Alt+Tab as a way to try to find the window I'm writing that email to someone.
I hate this too. You can turn it off. In Settings, go to System->Multitasking and change "Show tabs from apps when snapping or pressing Alt+Tab" to "Don't show tabs."
> This meant I could start the computer, log in, potentially start and use several applications and only then turn on the screen.
I mean... well... responsiveness matters to me too, and I am impressed by such inspired productivity, but... I'm also confused. Why not turn on the screen - the monitor, right?
Now thinking about how gui lag might impact the sight-impaired, tangential as that is...
It was meant as an example, not a productivity tip ;-)
Anyway the real point is that it's just easier to use something if you don't need constant visual feedback. Being able to use something blind is more than just an accessibility issue it is just better in general.
As someone who saw what impact WPF had on average users running average hardware in the late 2000s to early 2010s, I disagree.
In 2011, my brother was in seminary, using an average Windows Vista-era laptop that he had been given in 2008. When he was home for Christmas in 2011, we were talking about his laptop, and he told me that the Logos Bible software ran sluggishly on that laptop. He said something about how, for reasons unknown to him, the current version of Logos required advanced graphics capabilities (I forget exactly how he phrased it, but he had learned that the slowness had something to do with graphics). Bear in mind, this is software that basically just displays text, presumably with some editing for adding notes and such. At the time, I just bought him another laptop.
A few years later, I happened to read that Logos version 4 was built on WPF. Then, remembering my brother, I found this Logos forum thread:
This shows that Logos users were discussing the performance of Logos on machines with different graphics hardware. For a program that was all about displaying and editing text, it shouldn't have mattered. WPF had made a bet on then-advanced graphics hardware for reasonable performance, and that was bad for these users. And that's just the one example I know about.
"WPF had made a bet on then-advanced graphics hardware for reasonable performance, and that was bad for these users. "
OTOH WPF is today surprisingly strong GUI platform if you just want to get your Windows GUI out there.
It runs really nicely even on low end hardware. All the nice styling and blending techniques now _just work_ even on the most cheap low end laptop.
The fact it's over decade old means all the LLM:s actually know really well how to use it.
So you can just guide your LLM to follow Microsoft best practices on logic development and styling and "just add this button here, this button here, add this styling here" etc.
It's the least annoying GUI development experience I've ever had (as a dev, non-designer).
Of course not portable out of the box (avalonia is then the ticket there).
If you want 3D, you can just plug in OpenTK with OpenGL 3.3. Decades old _but good enough for almost everything_ if you are not writing a high perf game.
Really, WPF plus OpenTK is a really robust and non-surprising development platform that runs from old laptops (eg. T14 Gen 2 per my testing) onwards.
I've been doing a sideproject using WPF and OpenTK - .net works really great - here is a sample video of the whole stack (from adashape.com)
I had the misfortune of writing a complicated WPF app from scratch circa 2010-2011. Performance using the WPF widgets was terrible compared to HTML/Javascript/Blink; we ended throwing away most of the WPF code other than the main shell and a few dialogs, reimplementing the importantant stuff with immediate-mode Direct3D/Direct2D to get the necessary speed.
I recall wasting a lot of time staring at decompiled .NET bytecode trying to understand how to work around many problems with it, and it was clear from the decompiler output that WPF's architecture was awful...
It goes back pretty far. Nowadays the controversy is electron vs native (where most windows devs would consider WPF/.NET a native option).
But if you read books from the 2000s, there was much discussion about the performance overhead of a VM and garbage collected language; something like WinForms was considered the bloated lazy option.
I’m sure in a few years computers will catch up (IMO they did a while ago actually) and Electron will be normal and some new alternative will be the the bloated option - maybe LLMs generating the UI on the fly à la the abomination Google was showing off recently?
FWIW Apple has made a similar transition recently from the relatively efficient AppKit/UIKit to the bloated dog that is SwiftUI.
A notable example I remember from around 2010 was when Evernote dropped WPF, supposedly due to blurry text issues but probably also performance (remember when we called it EverBloat?)
Can't find the original blog post about it but here's a couple mentions of it:
Blurry fonts was my main issue with WPF. I get headaches from blurry text and the colour bleeding from ClearType just makes the headache worse.
Fortunately for me, I had mostly switched to Linux by that time already, where it was at the time relatively easy to just enable grey scale AA with full hinting.
In recent years this has gotten worse again with modern software incorrectly assuming everyone has a High DPI monitor. My trick has been to use bitmap fonts with no AA, but that broke in recent versions of electron, where bitmap fonts are now rendered blurry. So I had to stay on an old version of vscode from last year, and I will be looking to switch to another editor (high time anyway for other reasons).
WPF originally had two major rendering issues. One was the lack of pixel snapping support, and another was gamma correction issues during text rendering, particularly for light text on a dark background (due to an alpha correction approximation, IIRC). The two combined led to blurry text in WPF applications.
These were finally improved for WPF 4, since Visual Studio 2010 switched to it and had a near riot in the betas due to the poor rendering in the text editor.
I would argue that was less that WPF was the wrong life choice and more that Microsoft shouldn't have bent the knee to Intel's antitrust push to say their crap hardware was sufficient. [1]
Your argument presupposes that we should accept escalating baseline hardware requirements as good or even necessary, for a desktop computing world that was, from the user's perspective, doing pretty much the same thing as before. I reject that.
Yes, text shaping and layout are complex. My point is that the program wasn't doing anything that should have required a GPU, particularly for the resolutions that were common back then.
Not really. Ironically, WPF designers wanted to make things better by offloading the rendering onto the GPU. They also added DirectWrite that was supposed to provide high-quality text rendering with all the bells and whistles like layout for languages with complex scripts, in hopes of eventually offloading the text rendering as well.
But they just plain failed to execute well on this idea.
The fact that software to show the bible needs a GPU is funny in some kind of dystopian way. That is the kind of software that should work in 50k of memory.
The deeper problem is that Microsoft keeps trying to solve GUI consistency at the framework layer instead of the design system layer. WinForms, WPF, UWP, WinUI -- each one a new framework, each one eventually abandoned.
Apple solved this by treating the design system as the product and letting the framework be invisible. Microsoft has it backwards every time.
> The deeper problem is that Microsoft keeps trying to solve GUI consistency at the framework layer
I really don't think that's the fundamental issue.
TFA points out, and I agree, that the fundamental issue is political: competing teams across different divisions coming up with different solutions to solve the same problem that are then all released and pushed in a confusing mishmash of messages.
I haven't written a line of code for a Windows desktop app or extension since early 2014, when the picture was already extremely confusing. I have no idea where I'd begin now.
My choice seems to be either a third party option (like Electron, which is an abomination for a "native" Windows app), or something from Microsoft that feels like it's already deprecated (in rhetoric if not in actuality).
It's a million miles from the in the box development experience of even the late zero years where the correct and current approach was still readily apparent and everything you needed to move forward with development was available from the moment you opened Visual Studio.
There's just so much friction nowadays, starting with the mental load of figuring out the most acceptable/least annoying/most likely still to be supported in 5 - 10 years tech to use for solving the problem.
Honestly, things like Electron are quite literally the problem!
All of people’s modern desktop woes begin and end at the browser. Here’s why: the late 2010’s push into the cloud made JavaScript all-the-rage. A language the creator made in pretty much a weekend coding session.
There naturally is major business incentives powering this. SaaS made things MUCH easier for delivering software.
Fast forward 15 years and MSFT is full in on TypeScript. It’s a disease that starts with MsOffice and percolates to the whole OS (same as what’s happening in copilot).
.Net is actually elegant in many ways. You have PowerShell, VB .Net, C#, F# etc. languages of many paradigms all targeting the same bytecode (and supported by the OS).
And this is being replace by a fun little JavaScript thingy.
I mean Cocoa and SwiftUI are more consistent in the sense that a lot of stuff automatically adapts when Apple changes styling. And they certainly have less churn and more focus compared to Microsoft.
Basically it's been Objective-C and Cocoa since around 2000, later on Swift and then also SwiftUI. That's not too bad for 25 years.
And in contrast to MS, you didn't get abandoned when you were sticking to the official frameworks. Quite contrary, you basically got the switches from PowerPC to x86 to ARM almost for free for example.
Apple is not perfect by any means, but in this regard I truly think they are ahead of Microsoft.
You can't just take 40 years of Win32 apps and add the Metro design language, touchscreen compatibility, or dark mode system-wide. WPF nowadays has a skin that imitates WinUI, so at least Microsoft is trying.
The deeper problem is that all these layers are still in use somewhere within Windows. Try to give your Ethernetcard a fixed IP Address for example. On your way to the correct setting (which has visually looked that way when I was still going to school) you will move through maybe 3 or 4 layers of UI paradigms like a freaking media archeologist. Each of the newer layers dumbed things down and kept the old thing as a fallback.
Meanwhile in MacOS they dumb things down without a fallback.
The only people who appear to make serious attempts at improving the usability of computers are the likes of KDE and other Linux desktop environments. It used to be the way that Linux was the thing you used despite its shortcomings compared to commercial OSs..
WinForms is a layer built on top of raw Win32. So it's not portable.
Even though Wine exists, Win32 calls can only be made from Win32 programs, not native Linux programs. So a WinForms app using the latest dotnet would need to run the Windows version of dotnet under Wine, and not use the Linux version of dotnet.
Snide and subjective comments aside, you’ve clearly missed their point.
Even if you take away subjective opinions on Liquid Glass, the point is that the core system updates things across the board.
Unless apps have implemented custom drawing, you get a consistent-ish UI (for better or worse) across the system, whereas with windows you are beholden to whatever hodge podge of UI frameworks were chosen at the given time.
2 things Microsoft failed to do in the last 15 years are:
1) They abandoned their mobile phone, tablet, and wearable strategy. So, today if you develop a native Windows application, it will only work on desktops and laptops. That is it. It is not attractive for a developer to learn a whole new UI framework just to target a single form factor. And I don't know if there is any solution for this at this point, they shouldn't have completely abandoned those markets.
2) They did not back 1 UI framework for a long time (I mean 10 years+), instead they did significant changes to their UI framework strategy every 3-4 years. It takes a huge time for developers to trust, learn and develop complex and polished apps in a UI framework. Also it takes a long time for a UI framework to become mature. If you change your UI strategy every few years, you will never have complex and polished apps written with it.
To be honest I am not sure if Windows will ever be able to recover in the long term and keep its market share. The only reason it seems to be alive is because enterprise runs on Windows and it is hard to change that.
I feel like an Apple + Google dominance will be more likely in the long term for desktop operating systems. I am not sure if Google will be able to avoid the first mistake I wrote above but they are working on bringing Android to desktop. It is a good idea but it requires at least 10 years of supporting and polishing it despite not getting much traction. But if Google persists, we might be all using MacOS and Android on desktop 20 years from now.
Yeah, a striking difference between windows and linux at this point is that the linux UI frameworks are hyper stable. If I want to make a linux desktop app, I'll choose QT or GTK. Heck, if I want to make a windows and macOS app, I'll probably choose QT or GTK.
What do I chose with Windows? Who knows. It literally changes every time I look into it.
That's just insane.
It's gotten so bad that probably the right way to do a modern windows desktop app is react native. At least you could predict that it will stay up to date with the ever shifting decisions at MS to create and abandon UI frameworks.
Windows Forms is the answer you seek. It still receives updates to this day. I've been writing and shipping Windows Forms apps for 25 years. High DPI, dark mode, Edge web views, Blazor integration, we've got it all. Users don't even need to install .NET these days with self-contained deployment.
I will boldly claim Windows Forms is more stable than Gtk and Qt. Don't let random teams at Microsoft confuse you because they released yet another unrelated framework that you don't have to use. They are engineer-sirens trying to lure you from the true path. Let them pursue their promotions in peace while we rely on a stable workhorse.
On Windows, I would chose WinForms. Even today, even over WPF. It's as stable as QT and GTK, still supported, and has a large community of contributors and 3rd party vendors.
They had great devices before iOS/Android and then again after. That Lumia phone was awesome. They had one of the best cameras. Their live tiles they had on the phone & desktop OS were really good. Even Windows 8 had a cool CRM app in its infancy that tried to link all your social media & email accounts together.
They killed all of that even with multiple chances to win people over. It seemed they wanted to win the new markets in less than a year.
For as much flack as Google gets for short lived awesome products, Microsoft is right up there. Which is why when they've announced new things like Blazor, MAUI, etc., no one expects them to live long enough to trust their apps on.
I also strongly question their enterprise MOAT when most kids are growing up on Apple & Google devices the past decade. Microsoft seems to lack long term strategy.
> They abandoned their mobile phone, tablet, and wearable strategy
They were way too late to make a dent. Ballmer made the mistake when the iPhone came out to not get their ass in gear to compete. Microsoft's first potential real competitor to the iPhone came with Windows Phone 7 at the very end of 2010. The iPhone was announced in January 2007 and they didn't have anything to compete until almost 4 years later. I'm not sure how they could have recovered from that by the time they gave up on Windows Phone/Mobile in 2017. Anyone who worked in mobile sales at that time knew most people who did buy a Windows Phone ended up returning it when they realized none of their apps were there. They could have had apps if they recognized the iPhone's threat earlier and reacted appropriately.
Also worth mentioning that in their time competing for mobile they did a fairly hard reset of the platform 2 more times for Windows Phone 8 and Windows 10 Mobile. Go find what developers who tried to keep up have to say
MS ended up where it was at because there was basically NO upgrade path between the few different GUI frameworks they had. They broke the whole thing in 2002 when they decided .NET was the way.
You had to basically retool your whole GUI for whatever they were pushing at the time. Then they basically abandoned win32 GUI items and put them in mothballs. Then change their minds every other year.
No sane person is going to pick that model of building an application. So the applications kinda stagnated at whatever GUI level they came into being with. No one wanted to touch it. If I am doing that why am I sticking with windows? I can get the same terrible effect on the web/mobile and have a better reach.
Even their flagship application windows is all over the place. If you click on the right thing you can get GUI's that date back to windows95. Or maybe you might get a whitespaced out latest design. It is all over the place. It has been 10 years at this point. They should have that dialed in years ago.
I do not think Google will be able to pay attention long enough to have a stable GUI. Apple maybe. As for MS you can see it from the outside there are several different competing groups all failing at it.
MS needs another 'service pack 2' moment. Where they focus on cleaning up the mess they have. Clean up the GUI. Fix the speed items. Fixup the out of the box experience (should not take 4gig of used memory just to start up). Clean up the mountain of weird bug quirks.
I remember when ChatGPT exploded and Bing had it integrated, the idea was brilliant because unlike ChatGPT it didn't have information cut-off since it can access the web. I was very excited to ditch Google for AI chat with web access.
How did MS actually implemented it though? After a few messages the chat is blocked because MS did not choose to walk the extra mile and maybe compact the context so that their product can be actually usable.
Of course OpenAI, Perplexity and others later implemented that properly and its integral part of modern AI chat and I actually ditched Google for the most part. Had Microsoft done it, they might have had a shot in replacing Google and maybe becoming the AI Chat provider. But no, Microsoft can't have a well thought UI to provide a delightful UX.
IMHO it's a culture thing. Lack of cohesion is a result of it, I used to be annoyed by Apple that doesn't allow to ship its own UI libraries together with the app so to support old versions etc. but Apple had it right, thanks to the limitations UI is coherent.
There’s a poster on here who keeps posting and re-posting about their dinner with a Microsoft executive and how they were told Microsoft is all-in on enterprise. Waiting for that copy-paste to make its way over here.
Microsoft keeps footgunning things so hard I think even enterprise might be reluctant to go with them moving forward [0]. I don’t have Netcraft numbers in front of me but I doubt things have notably improved even if they do have a strategy shift to enterprise which includes crapping all over Windows for no good reason.
I’m personally glad FOSS is going strong but that’s a complete aside.
[0] We got burned by Azure as I’m sure many other enterprises have, and they did exactly nothing to remedy/compensate the situation, SLAs be damned. At this point our strategy is to move off of reliance on any Microsoft/windows tech. We moved off of ActiveDirectory not too long ago. Bing/Edge/etc honestly who cares.
Crucially, at enterprise sales, those who make putchase decisions are not the actual users (except maybe for Outlook and Excel). They sometimes play golf together with vendors though. This is how stuff like MS Teams of Oracle Forms gets sold: it checks all the compliance boxes, has support, an SLA, "is industry strength", etc.
imo the resizing test is not useful because it's a useful test of a common operation that needs to be optimized, but because it flexes on every major subsystem of the GUI framework.
Another example is startup time. Time to first frame on screen should be less than 20ms. That doesn't mean time until first content is rendered, but time until _all_ content is rendered (loading dialogs, placeholders, etc are better than nothing but entirely miss the point of being fast).
The second example is why even though I understand why developers pick tauri/electron/webviews/etc I can't get over how fucking slow the startup time is for my own work. None of them could show a blank window in under a second the last time I tried.
Sorry but neither Linux or Windows lag to resize windows in any of my 4 machines.
They range from old laptops to a Ryzen 7 9800X3D workstation.
Just yesterday a friend's father needed help setting up their second-hand old laptop with an old i5 processor. I slapped KDE and there was no lag to be seen.
Bonus point that Windows and some Linux distros have sane, intuitive window management. Whereas with macOS I keep seeing someone suggesting some arcane combination of steps to do some basic things with replies to the effect of "OMG thank you so much, this needs to be known by more people!!!"
I see frame drops when opening the start menu on a clean Windows 11 install on my work laptop (Intel Quad with 32GB memory from two years ago). I have seen the same on 3D Vcache Ryzens on systems from people who claimed there was not lag or sluggishness. It was there and they saw it once pointed out, the standards for Windows users have simply gotten so low that they’ve gotten used to the status quo.
On MacOS, meanwhile, Finder refuses to update any major changes done via CLI operations without a full Finder restart and the search indexing is currently broken, after prior versions of Ventura where stable functionality wise. I am however firm that Liquid Glass is a misstep and more made by the Figma crowd then actual UX experts. It is supposed to look good in static screenshots rather than have any UX advantage or purpose compared to e.g skeuomorphism.
If I may be a bit snarky, I’d advise anyone who does not see the window corner inconsistencies on current MacOS or the appealing lag on Windows 11 to seek an Ophthalmologist right away…
KDE and Gnome are the only projects that are still purely UX focused, though preferences can make one far more appealing than the other.
If we're talking a simple "hello world" window then sure, you can resize that at 60fps on pretty much any system.
But most nontrivial apps can't re-layout at 60fps (or 30fps even).
They either solve it by (A) allowing the window to resize faster than the content, leaving coloured bars when enlarging [electron], or (B) stuttering or dropping frames when resizing.
A pleasant exception to this I've noticed is GTK4/Adwaita on GNOME. Nautilus, for me at least, resizes at 60fps, even when in a folder of thumbnails.
On the Mac side, AppKit, especially with manual `layoutSubviews` math easily hits 60fps too. Yes it was more complex, but you had to do it and it was FAST.
My work laptop will stall on resize constantly, and I suspect it is due to the mess of security and backup software. Windows does have an ecosystem problem.
I am also baffled by the multiple control points. I can log in to mail in 3 places. Settings have 3 with different uis....it is gross.
I used to be a software test engineer at Microsoft in the late 90's and early 2000's. What I learned is that 60% of their business was International because of their language support. Also most of their customers are business customers locked in to using their Windows Server Domain system for corporations. These corporations also run office and Sharepoint and build custom apps using office. This is why they have so many different ways to build apps on Windows. We are not the users they are targeting, they target the enterprise.
Java wanted to run your code everywhere so they basically wrote a byte code compiler and then wrote one vm per OS/architecture
I never understood.NET's purpose. What problem it exactly went out to solve? Did Microsoft want developers to be able to run their applications everywhere too? Absolutely not.
Sidenote - MFC is the ugliest thing you'll see. Yet they didn't mention another piece of work called ATL. Active Template Library.
WinForms were really decent and that was enough. Keep Win32 API and a managed wrapper around it as WinForms and that would have been more than enough.
FWIW, x86 has always been a pretty moving target with many instruction set extensions, especially for various SIMD features. But even something fundamental like `popcnt` has a separate CPUID flag, even though Intel considers it part of SSE4.2.
Targeting the broadest possible variant of x86-64 limits you to SSE2, which is really not very capable outside of fairly basic float32 linear algebra. Great for video games, but not much else.
Also keep in mind that .NET originated right at the cusp of x86-64, which again is a whole different architecture from its 32-bit predecessor. Most native apps used to ship separate binaries for years.
And of course, I think Microsoft was aware of their intrinsic dependency on other companies, especially Intel. I can see how the promise of independence was and is enticing. They also weren't interested in another dependency on Sun/Oracle/whoever maintains Java at the moment. While Windows on ARM64 is still in a weird spot, things like .NET are useful in that transition.
Lastly, the CLR is different from the JVM in a number of interesting ways. The desktop experience with the JVM is not great, and Java is a very bad language. It makes sense to do your own thing if you're Microsoft or Apple.
I doubt that .NET was meant to solve the problem of underlying variation in instruction set of Intel processors because that concern does not exists for 98% of the applications anyway they rarely have to look for the compiler settings and for the rest of the 2%, the compiler flags are huge set of options and that kind of tweaks are NOT available for .NET anyway.
Additionally, such applications that want to exploit certain underlying processor's instruction set have no way to do so without detecting CPUID and landing into so called "unmanaged code" because .NET is all about very high level IR that even has object oriented features as well.
> What problem it exactly went out to solve? Did Microsoft want developers to be able to run their applications everywhere too? Absolutely not.
So .. initially it was "Microsoft Java", a managed language with tight integration into the Windows APIs, and non-portable. That was .NET Framework. A while ago they realized that even Microsoft didn't want to be tied to one platform, and moved to the cross-platform ".NET Core". It now occupies a similar role to Java but is IMO nicer.
Is MFC that bad? I'm inclined to learn it now and see it with my eyes. I dabbed into Win32 programming for a bit (really just a bit, like a few days) and it was tedious, but not really anything bad.
in its beginning .NET was a wrapper around ActiveX and Com-objects and it tried with C# to replace Java (disregarding the Virtual J++ attempt). as their own JVM did not meet the license agreement they made with Sun. so there were several reasons and not every reason being one a developer would care about
For others like me that didn't know the term Sherlock:
It means "To obsolete a unique feature in third-party software by introducing a similar or identical feature to the OS or a first-party program/app." The term stems from Apple's 2002 release of Sherlock 3, which made a popular third-party app named "Watson" irrelevant.
Ugh that brings back bad memories. I remember it was supposed to be the answer to MFC. I did an internship where my boss wanted me to use it. It was very painful because it had basically no documentation at all.
Wow, totally ignores the one framework Microsoft developed that was actually a pleasure to use (WinForms). Avalon sucked IMO; it was just a continuation of the fever dream at the time of making everything XML (or XAML in that case). MFC sucked because it was C++. WinForms was that brief Window of “modern programming language with simple, elegant GUI framework”.
I know it’s not a popular opinion, and I am sure there were reasons Microsoft abandoned it, but that was a brief few years when I actually enjoyed building GUIs on Windows.
WinForms apps always felt "tight" compared to all the other options (the development experience and the end product), and there were lots of 3rd party controls available. If you were building windows desktop app in the early .NET days it sure seemed like the way to go, and those apps lasting so long looks like a supporting data point.
EDIT: just dug out a "memory magic" winforms app I wrote sometime in the early 2000's and ran it no problem, no weird looking non-native UI or long electron startup...
The 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!. I use Windows every day but I almost exclusively develop cross-platform systems based on the WWW, Java, Python, etc. Whenever I have developed with .NET it has been for a cross-platform front-end like Silverlight or Unity/itch.io.
I can’t say I have a desire to make a native Windows GUI app when I could make a web app: like if it worth doing from my computer isn’t it worth doing it on my iPad from anywhere with Tailscale? For all the complaints about modern JavaScript it gives you the pieces to make a very pleasant world in terms of DX and UX and you certainly don’t need to ship an Electron runtime for many applications.
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 make sense.
Just build for the web. You can package web apps for all the major app stores using PWABuilder[0], no Electron needed. Just fast, lightweight apps distributed by app stores and accessible from the web.
> 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 make sense.
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.
> 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 make sense.
You mean the hypertext platform that has been shoehorned into Java's paradigm, suffering from the same boof-o-rama as Windows, and whose lowest common denominator to support must be Safari for iOS?
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.
Seems to me the point of the web is: no app store bullshit.
On the web if I want to publish a web app... I publish the app. If Apple things my app isn't good for their business... tough luck for them.
If I want to update a web app... I update the app.
If a user wants to use an app... They visit a URL and the app is there! No having to face id, go looking for the app in an interface that's designed to hide the search function, that is filled with spammy trash imitation apps (that somehow get approved by the app store anyway)
All the time I hear somebody crying that their developer account got canceled and I want to say "what did you expect? the contract for a developer account is a suicide pact for your business." Stay free!
> 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?
There are other options besides "web app" and "only one OS". A cross platform app which uses something like GTK or QT will be a massively better experience for your users, one a web app cannot hope to equal.
Windows until 24H2 (when Edge and the last remnants of IE were replaced by Chrome) supported HTML apps [1], introduced with Windows 98 Active Desktop. They weren't used much but actually not that bad for end-user needs.
When Windows wants to nag you it makes marketing-oriented screens that I think are visually attractive in a commercial way if not quite as 'cute', 'cool' and 's--y' as a gatcha screen from a mobile game. These sure look like they were drawn with an HTML-based rendering system and if they weren't, they were certainly inspired by commercial art on the web.
When MacOS wants to nag you it pops up a Liquid Glass vandalized version of the 1999 retread of the modal confirm dialog from the 1984 MacOS.
I wish both of them had NEVER OPEN A MODAL DIALOG THAT I DIDN'T ASK FOR EVER AGAIN button that took 80% of the space and a tiny little greyed-out link at the bottom that said "maybe just maybe I want to hear about this in three years" but from a graphic art viewpoint I laugh at MacOS.
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.
At this point one must ask if Microsoft is still a software platform company - whether their products form a substrate where an ecosystem can form and build a coherent software environment for the users of their platform.
Microsoft used to be the Windows company (after being the BASIC company, then the DOS company). Then it became the Office company. Now it’s SharePoint and Office365 and Azure, a utility. Windows is a relatively small part. Office is both desktop and web (and spacecraft, where they have two versions of Outlook and none of them works). If you are confused at this point, so am I. There is no vision as to what Microsoft is. If Satya Nadella knows what Microsoft is, he isn’t communicating it properly. It’s not Azure, because there is also Office and Windows. And on-prem server products. And a line of hardware products. And stores (do they still exist?).
MS has never been a software platform company. That's the fundamental reason behind the issue the article talks about.
MS has always been a software application company. Windows was never anything more than a way to sell MS applications--and Windows 3.0 and later wouldn't even have existed in the first place if IBM hadn't dawdled so long over OS/2. Even in the MS-DOS days, when MS was reaping the benefits of IBM's previous bonehead decision to hand the PC OS market to them, MS was selling Office applications--on the Macintosh.
The basic Windows API, in all of its many incarnations, has always been a second-class citizen; MS Office applications have always done their own things that other Windows applications couldn't do without using undocumented features that MS could change at any time (and often did). One could argue that the only reason MS even allowed third-party Windows developers to exist was so that they would, in the words of one of PG's essays, do market research for MS. When a third-party dev came up with something that got enough traction, MS would simply incorporate it into their apps.
Microsoft has always had a broad vision of itself as a technology company; I feel it's perfectly fine to not be able to describe Microsoft in one sentence without using platitudes like "empower every person on Earth to achieve more" or "put a computer in every home and every office" (both paraphrases of actual MSFT company mission statements), and I suspect many other current and former Microsoft employees would feel the same way.
IMO Microsoft's best long-lived products have always been both finished solutions to your problems and platforms to help you develop more solutions, and Microsoft leadership has always recognized this. Examples: Windows. Office. Dynamics (their Salesforce competitor).
But even if a product doesn't meet that "why not both?" ideal, there is always going to be room for it at Microsoft, as long as it is not only a good or at least mediocre product by itself, but also works to sell you on the whole Microsoft ecosystem. Sometimes that is a bad thing (see all the Windows adware for Bing, Copilot, and M365). But that at least is where Microsoft remains consistent.
Nadella thought he could take the reins and start yelling “Cloud! Cloud! Cloud!” and that would be successful. He doesn’t have a strategy and now that’s becoming apparent.
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.
Correct for the Windows 8 and 8.1 initial versions, it was already quite good with UWP on Windows 10.
But then they rioted internally to kill C++/CX (the only time they had something comparable to C++ Builder), Project Reunion got announced and misused from the original goal, porting WinRT back into Win32 killed .NET Native as well, most of the key team members left to Amazon and Google, Azure or AI teams, the team is now mostly interns or juniors from Microsoft India, no direction, and is a mess, naturally.
I went from a WinRT advocate, to pointing out devs to stay away from it, this is how bad they treated those that actually believed WinRT could be it.
Part of the reason was that WinRT was aimed at tablets and other low power devices, where unrestricted Win32 API use could drain the battery too quickly. They were trying to put the genie back in the bottle to have more control in this new ecosystem, like Apple enjoyed on iPad, etc. Much of the weird signing and app store evaluation was to make sure your app used only the blessed APIs and wouldn't, for example, stay awake in the background listening on an arbitrary port and drain the little tablet battery.
Painful and nonsensical from a desktop standpoint but also kind of impressive in a way.
My favorite example of that was when WinRT app .exe files could not be launched from the command line. Only via some Windows Store voodoo dance with approvals, signatures and "security" that made WinRT for developers essentially a dead-on-arrival technology.
I would not be surprised if you still cannot launch a fricking .exe.
Use JUCE as much as you like, but please, stay away from those 'out-of-the-box' horizontal sliders it seems to prioritize (given how they swarm in the many VSTs made with JUCE).
If sliders are vertical in the real world, there’s a reason for it that Bruce “Tog” Tognazzini summarizes perfectly:
“Most of us […] have our forarms mounted on a pivot we like to call our elbow. That means that moving our hand describes an arc, rather than a straight line. Demanding that pivoted people move a mouse pointer along in a straight line horizontally is just wrong.”
That sounds intriguing - are there examples of desktop apps (eg productivity apps) that are made with JUCE?
I'm already very familiar with JUCE in VST plugins, I have hundreds of VSTs made with JUCE and I love their UIs. But I don't think I've ever seen it for a standalone business application?
The JUCE pricing is certainly far more reasonable than Qt.
You can configure your JUCE project to build to any of the standard audio plugin formats, or for it to build a standalone app for the target platform (i.e. plugins, desktop, mobile, embedded) or indeed to build all of these targets, at once, in one build.
However, during app (i.e. non-plugin) development I often switch between linux and macos environments as part of my workflow, and during testing after I've pushed to the proper branch, the build server plops out the .exe/.pkg/.app/.tar.gz bundles as needed for the test group to crack at it.
JUCE, being at heart a C++ framework intended to be the engine of a very diverse swath of different OS, plugin, and packaging standards, does all the glue to get you there - how you use it, is up to you. (All of this can happen in github actions, btw, really easy to set up..)
Yes, there are 'business'/'productivity' UI elements in JUCE app targets, and yes they are consistent across all platforms. And yes, you can for example build a UI from an .xml form, with cross-platform datastore and so on, easily enough.
Here's a nice place to start, if you wanna understand JUCE capabilities from a 'productivity'-app perspective:
David Rowland, a core JUCE developer, explaining the guts of things.
Basically, the scope is high performance applications, and there are no really good reasons for why a high performance application cannot also be a productivity app - the distinction is arbitrary - except of course you ask, for the GUI!
But: JUCE' GUI is pretty darn good, I have to say, in face of the onslaught of platform vendor fuckery. You can embed a WebView if you really need it, and wire it up to the rest of the cross-platform event handing system, etc. But I think its not really needed, given the plethora of 'normal' UI controls, out of the box.
If you're serious about looking at JUCE for a variety of application types, then a lot of the questions you're going to have about JUCE' GUI suitability for standalone business applications can be answered by running the DemoRunner application that's built-in to the JUCE codebase.
Clone the repo, build the DemoRunner project for your platform (or all of them), and you'll see - there are plenty of business-like cross-platform UI elements in the kitty. A huge collection of business-/productivity- like UI elements, right out of the box. (High-performance plugin UI's are there with the business UI stuff, too.)
And .. once you've marvelled at the glory of DemoRunner(.exe,.app,.apk)[etc.] .. please do yourself a favour and spend an extra hour parsing the awesome-juce list:
When a platform can’t answer “how should I build a UI?” in under ten seconds, it has failed its developers. Full stop.
That's fine, except no platform answers this.
Obviously Linux doesn't, but the Mac doesn't either. Apple of course has it's recommendation, but most developers do not take Apple's recommended path because of course, it's Apple-only, most developers make cross-platform apps these days.
Even if Microsoft decreed the one-and-one Windows development path, most developers are not taking that path.
It used to be the case that Mac developers used Apple tools, Windows developers used Microsoft tools, but those days are gone. Developers want to use Electron, or Qt, or some other system to support multiple platforms in one codebase.
Microsoft has less to do with this than the article makes out. I'm a desktop developer. I don't care what Microsoft recommends, or what Apple recommends, because neither work in the real world where supporting only their platform just isn't realistic.
I think the mac mostly does this. Developers not caring about the answer is a different thing.
But I gather from your comment that you don't actually care to ask that question, since you have a different need, and already have a solution which works for you. Which I guess is fine if you're happy with the compromise.
But this is about people who actually still care to have "native" applications.
Linux can answer the question, but you're considering Linux as a monolithic platform which it isn't. If you ask "how do you build a UI for Gnome / KDE / Android?" then the answers are pretty clear.
Having spent some time kicking around the Delphi space I got quite into WPF in 2007ish. By 2010 I had not just sworn off it, I'd sworn off Windows entirely. The constant stream of rug-pulls as one bit of MS managed to pull off a political heist over another and - oh no - yet another "latest and greatest" technology was effectively deprecated within 18 months of launch, invalidating all the effort you put in to staying up to date just became a pointless treadmill.
Fortunately Rails was taking off at that point so it was fairly easy to change horses and just ignore it.
I've read this and the relevant chapters on his Substack and I think I get the idea that he tried to implement, but it's obvious in 2026 where his vision diverged from what people really wanted.
In the ideal world, Win32 applications would have automatically run in a sandboxed WinRT environment with granular permissions. A program thinks it's accessing a USB webcam, but it is actually accessing a Win32 shim that goes to the WinRT that first prompts the user to obtain the necessary permission and then goes to the real Win32 USB API to interface with the camera. A program is trying to access a file that hasn't been selected in the "Open file" dialog or dragged into it or passed as a command line argument? Raise a "malicious access" warning.
Overly complicated programs like antiviruses would have been able to get a "hall pass", either by registering their builds with Microsoft or asking for an administrator-level exception.
Of course, this would've been terribly hard to implement. Doing it natively would be supremely complicated, much harder than just designing a whole new userland API like WinRT. And sandboxing every application in something similar to Sandboxie would've been too taxing on the PCs from that time.
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 on scorching all the ground that wasn't theirs. My team actually did some prototyping for Python/WinRT support, and we had it working to the point of the visual WPF designer in Visual Studio even. Unlike JS, it was full fledged - you could use anything in WinRT same as C#, extend classes etc, while JS limited you to a "consumer" surface of the API. That prototype was killed because Windows (i.e. at the time = Sinofsky) said they didn't think developers cared about anything but JS so they didn't need another high level language.
It was also when Windows was aggressively pushing their Metro styling on everything in the company, sometimes to ridiculous lengths - e.g. Visual Studio at the time "aligned" with Metro by, I kid you not, making the main menu bar ALL UPPER CASE so that it looked like Metro tabs! You can still see the blog posts announcing this "feature" when it shipped in the first public beta of VS 2012, and the comments on them.
And then there was Windows RT (not to be confused with WinRT, because Microsoft product naming!). Aka the Windows-on-ARM that ditched decades of backwards compatibility because Sinofsky decided that rebooting the ecosystem is the only way to compete with iPad or whatever. What actually happened was that the users went WTF because none of their native apps - which, contrary to his take, were very much alive and kicking! - worked there, and devs went WTF because they were told that they'd need to rewrite everything yet again in some new thing that was kinda sorta but not quite like WPF, because Windows just hated .NET that much and couldn't accept that the devs liked it over their stuff. So the app store was a barren waste, and without apps there would be no users.
Some of the technical details in there are plain wrong, too. For instance, .NET 3.0 actually shipped in Vista, contrary to his claim that it was shipped in Win7 (and that it was the first time .NET shipped in consumer Windows - in fact, that would be .NET 1.1 shipping in WinXP SP1).
Sinofsky kept talking about how many devs were making apps in JavaScript and how they would just be at home in Win8. This was before React, ES5 (no native classes! or promises!), etc- jQuery was still very popular and SPAs were extremely rare. He completely overlooked how dependent many of these devs were on their servers- Python, Ruby, PHP, etc.
Often kind of person who makes such mistakes is the kind of person unable to learn from them. The post by Sinofsky is exactly as I imagined it would be.
> 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.
Yeah, he's talking about WinForms like it was a whole new thing, but it was a very transparent OO layer over Win32 and extremely similar both to VB and Borland Delphi. It was one of the reasons why .NET survived at all when Linux servers became the default option.
(disclaimer: I was an individual engineer in the Windows division during the Windows 8 project, i.e. reporting through Steven Sinofksy)
I think you're being a bit unfair to the Windows division during the Win8 lifecycle. Maybe that's just my rose-tinted glasses though. I know there are some HN/proggit commenters who like to harp on the supposed toxic rivalry between the Windows orgs and Microsoft developer tools orgs and how it has made Windows' developer platform much worse over the years, but I have always thought we had a better relationship than that, since my group's product was the main reason for yours for many years, and your group delivered so much for us in turn. Clearly your side had at least some reason to see things differently. On behalf of all of us, yes even up to stevesi, I'm sorry.
Now let me completely undermine my apology by nitpicking your comment :)
I have always been tempted to use WPF but I’m reluctant to learn a whole new language for side projects. Especially nowadays C# seems to be as huge as C++. Oh well maybe I should grit through the beginning phase.
It seems Windows division has too much power and they used it to break their things.
Also, Windows division is shipping a subpar product now.
In a sane world developer division and Windows division would think things together, developer division would produce the tools and the same tools would be used by Windows, other Microsoft products such as Office and third party developers.
Why that doesn't happen at Microsoft, I don't understand.
And I don't understand why Nadella doesn't do anything about it.
Is there any way to get to the article without going through x.com? xcancel.com just says "Nitter doesn't support this feature yet, but it might in the future."
Fun and sad. Garbage collected languages like .NET, Java, and Go are slow compared DIY languages like C, Rust, and Swift. So, no wonder the Windows team dislike them. However, it seems the Windows team had to live with a React start menu for quite some time. How does that fit into the over all battle between the teams and UI frameworks?
That wasn't the issue. The problem was that most of Windows system utilities are not managed, but the WPF move was trying to make a patchwork quilt of managed vs. unmanaged utilities, making the entire system very difficult to reason about and introducing regressions constantly. From the Windows Team's perspective, the .NET people just made a mess out of everything they touched.
Perhaps if WPF really did stay at the presentation level, or used VMs or something to keep it away from the Windows core, it would have panned out better. But is it goes with "paradigm shifts", when a company thinks it has a great idea, it wants to suddenly do that great idea everywhere.
Which one? The classic QtWidgets, which implements consistent controls but sometimes talked about as deprecated (same as WinForms), or QML, which is "modern" and "actively developed" but does not provide native look and feel and requires (or at least used to require) a lot of manual work to support proper keyboard control and accessibility?
The biggest issue in my opinion is that Microsoft is chasing web devs. XAML is pita, just like css and html markup. They need to pick a lane and just use it. Allow other frameworks access to the default low level api such as Win32, but document it to the same level as Google does on Android and Apple with SwiftUI
I actually like the idea of GUIs being represented in a markup (whether that be XML, QML, GNOMEs new Blueprint (which is kinda a markup language I think?) but I also thought display postscript was elegant so maybe I'm backing the wrong horse
I think the whole world sails on that ship and MSFT just wants to catch up. Their most darling developer tools since 10 years ago are mostly by web and for web: Typescript, VSCode.
I remember I was trying to learn GUI programming in late 2000s. I took an attempt at MFC but no matter how hard I tried, it just didn't make any sense. Then I found out about Qt 4 and it felt like magic immediately. I ended up working as a professional Qt software developer for 3 years.
Fast forward to now, and KDE Plasma is state of the art Linux desktop that I've been daily driving for years. It's also built on Qt.
I haven't touched it in years but I remember moving to WPF because it had a better answer for binding UI elements to data. But while WPF does have an answer, everything is so fucking verbose and clunky.
It is a wrapper, but it's not quite on the same level as MFC. MFC really is a thin wrapper, almost 1:1 in most places. WinForms is more like VCL or VB6 in that it uses Win32 where it can but doesn't design around it, so in practice it's more high-level.
SDRPlay is using Avalonia for its SDRConnect desktop UI. That's the one native application based on Avalonia I've spent significant time in.
It's ok. I give it pretty high marks. There is a good deal of "lowest common denominator" in it, naturally due to cross platform abstraction. But, it's generally nice, and commercial licenses are affordable.
An honest accounting of this history has to call out Sinofsky's role, and it's not pretty. He nearly killed the company in pursuit of power, insisting that everything be brought under his control. Who pushed in 2005 that online and search had to be organized under Windows? That was Sinofsky. He forced the engineering team that most needed to move fast onto three‑year product cycles--sheer insanity, and just one of a 1000 bad calls that ultimately contributed to his ouster from Microsoft. And when it came time to plan his own exit from Microsoft, who did Sinofsky turn to? Jeffrey Epstein, of course, because that's what normal people do. Treat everything Sinofsky writes as an attempt to launder his reputation--then add another layer of skepticism on top of that--because Steven Sinofsky does not live in the same moral universe as the people whose careers and products he derailed.
As an outsider, it always felt that 'internal team politics' were the root cause of Microsoft's technological downfall. This went far beyond the GUI. In 'flagship' offerings like SharePoint or Skype/Lync/Teams you could see the unmixable partial code-bases brutally forced together under a single product name an foisted upon a user-base baffled by how this could have gone so wrong.
At Redmond, there was also the Patterns & Practices group (P&P) that tried to make sense of the dev products, and built extra libraries “to show customers how to use them”. They followed the bouncing ball of the frameworks releases from the main development teams. It suggests that it wasn’t clear exactly how you’d use the main products: so P&P said, ‘try it like this.’
I also think the article didn’t say much about MS in the web era. The company survived webdev IMO, but it definitely wasn’t the leader
Qt/Win is enough to get the job done. Not always pretty, but it works. I used to be somewhat ashamed I never learned the actual Win32 API to write native apps, but now it looks like that was time saved. This is a great article.
A couple of years ago I played a bit with Go and Win32.
I got to the point that I could create windows and controls, and had a basic message loop working.
I then started dabbling in painting in non-client areas. It was buggy and didn't work well (my fault), but then I could see 2-3 different Windows UI styles competing to draw the window chrome.
The amount of crumbs hidden under the Windows carpet is incredible.
Xaml and styling and all sorts to try and compete.
Trouble is, it made desktop development harder, and it didn't win against the web. It left the simple and safe formula of standard and common controls for a designer's playground, but the designers preferred the web. And if you make something for the web, you can package it in Electron and get cross platform cheaply.
Microsoft's biggest mistake was .Net being a Java competitor when it should have just been like golang producing native binaries. Especially since .Net was realistically only going to succeed on x86/64 at that point (late 90s and 2000s). This shut the door on C# for consumer UIs, and people stuck to Visual Basic and MFC.
It took them more than 2 decades to finally support pure native binaries (via NativeAOT). And it's fantastic for servers on Linux.
The problem was in the early 2000s it was basically accepted x86 was a dead end whose days were numbered.
Itanium was the heir apparent but importantly basically vaporware. How do you develop software NOW and more importantly sell and ship software NOW that'll work on a CPU you don't have access to and for which good compilers don't really exist yet? I remind you in the days where online updates were a luxury at best.
Processor agnostic CIL/JIT code was the prescribed solution at the time. Java had lit the way, and it was the only "clear" path forward for better or worse.
Little did we know Itanium would implode, and x86-64 would rise and give 20+ more years of binary compatibility.
They were recovering from all of the security fiascos of software that wasn’t being updated. So they pushed as much as they could into the core libraries and forced only one version to be installed at a time- so they could easily push security fixes.
This led to one of the trickiest things for early .NET consumer apps- getting the latest runtime installed.
I found the article itself very informative and not particularly ai-tastic. But then I got to that infographic at the end. Holy smokes was that disappointing. It seems clear they didn't even bother to read the captions the AI scribbled.
It starts out alright, and then ends with a pile of classic Claude-isms and an unreadable slop graphic. Like the author got bored of writing it halfway through.
I very much dislike WPF. If I have to do a windows UI (and usually when I do it's a simulator for some piece of hardware), I honestly just grab WinForms. It's stupid simple.
Same here. Also the benefit of a visual Editor in Visual Studio is just Premium. Windows.forms also allow all those „modern“. Takes on ui either with ownerdraw or some grids/hand layouting.
To quote Steve Jobs: "The only problem with Microsoft is they just have no taste. They have absolutely no taste. And I don't mean that in a small way, I mean that in a big way, in the sense that they don't think of original ideas, and they don't bring much culture into their products. "
Winforms is still compelling to me. Now that we have WebView2, building complex hybrid apps is trivial. I know I could easily go pure web, but something about having proper native chrome feels better as a user. All of my clients/users are on windows so I stopped fighting this battle years ago. I've recently been using .NET10 + Winforms + WebView2 to build custom ai assistants for others. I cannot imagine how much it would suck to iterate the presentation of a conversation history in pure win forms. The hybrid stuff is crazy productive.
I just looked into this a bit because I thought he still had some kind of role at Microsoft even after leaving as CEO/chairman, but it turns out that in 2020 he left any and all positions at Microsoft as it was investigating him over inappropriate sexual relationships he had with Microsoft employees.
Before that he had a role as a technical advisor and sat on the board of directors.
I also found it interesting that Steve Ballmer owns considerably more of Microsoft than Bill Gates (4% for Steve Ballmer while Bill Gates owns less than 1%).
He’s still around as a part time advisor, he has to officially step back or no one would take Satya seriously, but on important stuff like AI he is a bit more active.
If he doesn't use Windows, you won't hear about it. And if you hear that he uses Windows, it might not be true. He loses nothing by denying it. If it worked for his friendship with Epstein, it will work here.
> I sat through a conference session in the late nineties trying to understand the difference between an OLE document, a COM object, and an ActiveX control.
I wonder if we attended the same conference session!
A decade or so ago, I had a clear idea of what a "native ui" should look and feel like, even if there were multiple routes to get there. I don't know any more.
The roadmaps look messy if you look at them as coming from one company. But if you remember that windows and .net (or DevDiv) are more like competing companies then it makes more sense. Then for one side it’s Win32, MFC, WinSDk and for the other it’s Win32 (WinForms), WPF, MAUI
If Microsoft hadn’t been preoccupied with a failed mobile bet then this wouldn’t have happened. It’s a lost decade followed by a (much more successful) cloud pivot. The reason desktop is ignored is because it can be. No one is eating their lunch on desktop.
It is a fantastic book, I learned everything I know on Win32 from it. Wrote real time scientific software in windows for ~10y! We did it all, external hardware control, custom UIs, etc. Thanks Ryan Geiss for your timing info.
Right about VC6 was the sweet spot imo, C/C++ with lightning fast UI for docs and more. Tools got out of the way. Once other languages got involved (C#?) the docs got out of control and harder to use, and the UI started to get a little overloaded.
The snappiness of those old windows systems was pretty great.
The root of the problems seems to be trying to find a holy grail design that works across all their businesses. Surface tablet mode, touchscreen laptop, touchscreen desktop (surface studio), mouse and keyboard PC, stylus input, etc.
Then there's a lot of legacy stuff that needs to continue working because otherwise you end up with a non backwards compatible windows.
Then you have to get everyone at microsoft across all their bajillion products to change the UI from Task manager to the 5th level of settings for some obscure ODBC connector.
Both this blog post and the Steven Sinofsky response really set my blood boiling, because they both reek of retired-executive score settling, a kind of blame game that gets played out decades after the fact between ex-high-ranking people in hopes that whoever writes last is able to cement the conventional wisdom.
People who play this corrosive game either refuse to believe that they are at fault for not changing what they were doing at that time or speaking up about what they were observing then, or they know they're at fault and want to deceptively distract us from that fact. Either way, ask yourself this: "Aren't they sorry?" If they're not, just move on.
The most offensive part of the Sinofsky response is this part:
> WinRT (2012) - it (or the embodiment in Windows 8) failed in the market but it also showed both the problem and potential solution to building for new markets while respecting the past
I can't express how wrong this is. WinRT was the most destructive thing that the Windows team ever did to the OS. It drove a hard stake into Windows, splitting it in half and declaring that anything previous to Windows 8, oriented toward desktop, or using primary input through mouse and keyboard over touch was dead. Microsoft basically told all existing Windows developers that if they weren't building a new, touch-oriented, mobile-style app specifically for Windows 8, they didn't matter and wouldn't get any support whatsoever, which is exactly what happened every time they broke existing desktop functionality. Calling this "respecting the past" is a crass insult and taking no responsibility for damaging the Windows development experience and accelerating development away from native Windows apps.
I think for Sinofsky the "respecting the past" refers more to WinRT was/is still just Spicy COM under the hood. Most of the article as I read it is about how .NET was a mistake for Windows UI development and a return to (Spicy) COM its savior.
I used the more recent Petzold examples to successfully bind DirectWrite to Direct3D, but yeah it’s been a crapshoot otherwise. Still have the Windows Programming (5e?) bible around here somewhere. Took awhile to grind through it. I dread modern-day windows programming it seems like every OS release some new API is going to overtake the others. I moved on.
I blame "Impact". That's what you are graded on at Microsoft. Every performance review ('Connect'), every stock award, every promotion run: did this person have that magical impact.
Ostensibly, grading by impact is fine: they want people who make a positive difference. In reality, it means that creating is better than finishing. Now add in the cold realities that at any given time in Microsoft, some groups are on the up and some on the down. What's a great way for a group to regain some status? Launch something. Jazz it up for the Build or Ignite crowd. Get some dev evangelist to talk about it. Then get on the job board and slide over to another team ASAP. You're a High Impact person. Who wouldn't be happy to have you?
Not just Windows. If you use an Android smart phone (and it might be just as bad on iPhone I just don't know) you see AI features occupying the last scraps of user interface real estate in the form of edge gestures that half the time get me an unwanted AI overlay UI when I was looking for the app switcher. Steve Jobs is spinning in his grave, and the people who authored the original Mac UI guidelines are cringing. Nobody seems to be willing to say that there's no room at the inn, or that somebody's idea has to get evicted before a new idea can occupy space.
Microsoft itself is a business driven by a consistent strategy of striving for market dominance no matter the means. looking for coherence in the resulting DX is missing the forest for the tree.
MS Windows is walking joke for at least a decade, UI consistency isn't it biggest problem. Unfortunately both Linux and MacOS have their own deeply seated issues. This leaves users in an unenviable situation and encourages experimenting, with AI encouraging more and faster attempts. When AI are getting better... I hope this question will become unimportant sooner rather than later.
One could argue the 17 solution summary is actually correct? Why should an os be limited to just one way of doing things. I don’t believe my own words 100% but it is a thought that maybe diversity is the eventual outcome. Ubuntu and MacOS are kinda fighting the same battle. Is that just the way it is?
It's bad enough that Microsoft doesn't have a satisfying answer to this question, but what makes it worse is that WinUI feels weirdly non-native in ways that sort of uncomfortably result in Electron apps feeling more like real Windows applications.
It's worth noting though that Apple is on a similar trajectory and is now in a very nearly as bad position given all the serious issues with SwiftUI and how badly it has fragmented/degraded Mac desktop application development.
It's almost like the major desktop platform vendors have all given up on supporting high-quality native desktop applications.
> It's worth noting though that Apple is on a similar trajectory and is now in a very nearly as bad position given all the serious issues with SwiftUI and how badly it has fragmented/degraded Mac desktop application development.
Apple (and Next before it) have been iterating on Appkit/UIKit for three and a half decades.
Now they have added SwiftUI as a second option and have been iterating on it for a bit over half a decade.
This is in no way similar to Microsoft creating and abandoning another UI framework every couple of years.
If Microsoft had been steadily improving Win32 all these years, where would it be today?
The web revolution is to Windows UI what vibe coding is to programming today. It brought in a massive group of people who didn't need to understand message pumps, or handles or non-blocking api calls. On top of that, it delivered incrementally more capable result each year. View source taught millions how to build modals, blurred overlay. Meanwhile, the old group of programmers were still worrying about how to protect the knowhow behind compiled languages.
I agree with the thesis of your post, but where we differ is that I think both of those were (are) bad things. Both web apps and vibe coding are causing the market to be flooded with low quality software, not only making the market worse but also giving future generations fewer examples of well-made software to look up to.
Well, Edge is Chromium. They need to maintain a hard fork, not just a reskin with a bunch of Microsoft webpages and adware. Chromium basically allocates a window and completely draws everything inside using DirectX APIs including menus.
I was recently exploring "an OS from scratch" architecture with ChatGPT. Apart from the central idea that I wanted it to be a capability OS, I also started thinking about how I'd make GUI apps and what layers would naturally make sense.
The cleanest design I came up with works like this:
1. At Layer_1 OS provides panes or windows to which apps can render whatever graphics using OS gpu lib (think Raylib, but maybe a bit simpler). This is good for apps that want performance, games, text editors, things like that - so this is maximum control.
2. Next Layer_2 would be based on the browser engine (which, to some degree, would have to be developer - not a full browser, but just enough to render more or less modern html/css with a DOM-aware JS engine). Then provide some XML schema that would automatically translate into HTML/CSS to render various UI-widgets (defined by XML/HTML elements). This would eventually suggest a JavaScript UI framework on top, but no a requirement. This layer is flexible enough that it uses widgets defined by the system, but allows custom CSS and JavaScript.
3. Layer_3, or more like Layer_2.5 would basically allow custom HTML/CSS without relying on system widgets and XML schema.
Obviously you can mix all three layers into one GUI too. Finally layers (2) and (3) would require some client/server architecture, but instead of shipping it like a webapp, I'd probably provide some JavaScript API to talk to the backend (which in this case is accessible via a socket of some sorts). Apps themselves could still be single binaries that include html/css/js assets which are provided at launch time to the system UI renderer, which then uses them to render the UI via a webview in said pane or window.
I think it's pretty slick and it only gets complicated gradually, but it also requires solid OS plumbing and machinery to make this process smooth. None of the modern systems are capable of it in the way I described it, so people end up shipping nodejs/react apps with webview inside gigabyte-binaries.
While reading all these comments I keep asking myself if these are the same people who would get angry at another Election app because someone was lazy and didn’t make it native.
I had the displeasure to work with various MS systems over the years and coherence is not a concept in Redmond. It just isn't.
The layers of outdated and conflicting documentation, fragmented logins, the naming (365, live, .net [both naming everything that and the .net core naming labyrinth], copilot), Teams never made sense, Windows had levels and levels of settings (win10 preferences all the way back to dialogs predating the mammoth).
MS was, is and always be a blight upon this earth.
The UI strategy of the future may very well be HTML. It's widespread, standardized, sufficiently performant, and pretty rich.
What'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.
not exactly the same, but worth noting that in a spectacular display of being too early, microsoft shipped this 30 years ago (active desktop in 1997 merged the windows explorer with internet explorer, turning folders into web pages).
That was indeed a pain point, but not anymore after CSS flex layout became available some 10 years ago. It's not worse than WPF for sure. It's even better than WPF because you have access to tons of UI components and toolkits that work everywhere.
There's a competing webapp-wrapper framework that explicitly uses the platform's own browser, but developers don't like being at the mercy of whatever the OS ships...
> WPF shipped in late 2006. It was remarkable – XAML, hardware-accelerated rendering, real data binding. If Microsoft had made it the definitive answer and invested relentlessly, the story might have ended differently.
Er… The author perhaps never used it? WPF was the worst framework I ever used. It was unbearably verbose, brutally unforgiving, used 2-way bindings that created updating nightmares, ans not the least it was incredibly slow.
WinForms was not the best for sure, but at least you can get stuff done. It was for a long time the right answer to the question the author asked. .Net + WinForms worked well.
This is the common thread of all their frameworks since, and in my mind the reason they are stuck in an absolute quagmire. For a while it was possible to use HTML/JS in UWP (I think), but it didn't stick due to everyone already needing to move over their LOB apps with crazy amounts of XAML so that's what the focus was on.
"Hey, let's make something that's vaguely HTML but not really at all."
Big mistake.
Avalonia and Uno are repeating that mistake, even though with Uno, at least, there's a blessed way to do unidirectional data flow/reactive stuff.
The funny thing is that Joel Spolsky predicted most of it 20 years ago[0]:
>> Jon Udell found a slide from Microsoft labelled “How Do I Pick Between Windows Forms and Avalon?” and asks, “Why do I have to pick between Windows Forms and Avalon?” A good question, and one to which he finds no great answer.
And:
>> Which means, suddenly, Microsoft’s API doesn’t matter so much. Web applications don’t require Windows.
What he didn't see is, however, Azure would become the money printer for Microsoft and made all these no longer matter.
IDK, it kind of sounds like from the article's own prose that Project Reunion / WinUI 3 is an overall good thing and that Microsoft actually does have a pretty good vision for the past 5 years at least.
From a user's perspective, I don't really see where the problem is. All my apps look like Windows apps to me, and I also think that includes apps that do their own thing and look their own way. For as long as Windows has been around we've had apps that just don't follow the rules, from RealPlayer to WinZip to iTunes to Spotify.
This idea that all applications must be consistent with each other on one platform is generally a good idea but the downside of not having it that way is not very tangible to most users.
E.g., Steam looks different than every other Windows app. Same with Spotify and Slack and Discord. How does that negatively impact users? Well, not really at all. The consistency is within those apps themselves. I'm comfortable with Steam because I've been using it for 20 years and it's evolved on its own terms.
I could see it being an accessibility problem, but can't figure out any other potential downside.
I also don't think any other platforms have this figured out. See the window corners in macOS Tahoe. Remember how Mac Catalyst apps first looked when that came out? They didn't follow OS conventions at all. Remember when Final Cut Pro 6 didn't look anything like a Mac app? Or GarageBand etc. and their skeuomorphic looks? Linux is no better with a mix of desktop environments, Wayland versus Xorg, etc. Then we look at mobile apps and it's one of the least consistent environments imaginable: you've got a mix of native and frameworks like React Native and Flutter and the rest.
This will never change. All large orgs are this way because at the end of the day, unless its preventing them from making profits, there is no incentive to change it.
Moreover, there isn’t much in the way of alternatives. Everyone likes to hate on MS —for decades this has happened and nothing came of it.
Anyone else sit through one of those Microsoft "Project Reunion" and wonder "what the hell is even this?" Microsoft has had a completely confusing UI strategy for years.
Starting with Metro every Windows UI framework has been beyond ugly. there's just something so backwards over how nice the UI was in Windows 7, I simply can't understand it.
Metro was created partly to run smooothly on cheap Atom tablets and Windows Phones. Then Microsoft shifted their focus elsewhere and iOS 7/OS X Yosemite happened so they have all the reasons to stay flat.
Updated apps look fine, but the majority aren't. And with that bizarre "Show More Options" nesting in the Windows 11 context menu it almost seemed like Microsoft is no longer capable of upgrading old components in place.
At this point I don't get why they don't open source Windows and developer tools, make a foundation to steer the code, accept contributions and borrow ideas from other operating systems.
Nobody 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.
KDE has the newer QML-based Kirigami and older Qt Widgets frameworks that are not consistent. Widgets apps absolutely look like actual desktop apps (menus, toolbars, dialogs), Kirigami apps look like mobile apps (nav bars, hamburger menus, page-based navigation). There is definitely a visual and functional inconsistency between the two, even if they use the same theme pretty well.
Every year the same debate, every year the same Microslop apologists in the comments, every year nothing ever changes, every year Microslop's market cap keeps groing, every year the same problems
Microslop should have been dismantled decades ago, it's now too late, we need a paradigm shift so that Microsoft no longer affects our society
I'm not sure I can take such an article seriously if it doesn't mention that the WinRT/UWP/WinUI stack is also based on XAML, and that a fundamental design goal of WinRT was to let people use either C++ or C# according to taste.
Also, the AI smell in this article is just too much.
Here's how I think Microsoft can get a quick and sustained longterm win in GUI (/s but only partially) -
1. Drop all its GUI stacks apart from legacy Win32
2. Port KDE Plasma to Windows (with aliased bindings to support traditional explorer.exe calls so as to not break user apps)
That's it. There really aren't many significant apps that use the rest of Microsoft's stack apart from Win32 that won't recover from this, and Microsoft itself will just see a massive drop in its own costs with a massive rise in user satisfaction.
Oh hey look, another chance for HN to dunk on Microsoft. I’m sure there will be some fresh new perspecti…oh darn, it’s just a rehash of the exact same snark the last time HN had a chance to dunk on Microsoft.
I’m not sure what Microsoft can possibly do when the closest thing to a collection of power users is this painfully repetitive.
> Dead silence. One person suggested WPF. Another said WinUI 3. A third asked if they should just use Electron. The meeting went sideways and we never did answer the question.
Yes they really do a great job at mimicking awful human writing of that horrendous style, whatever it's called. Post-TED NPR style bougie blogging let's say.
Dead silence. Here's what 3 people said (the opposite of silence). Then the meeting went sideways (also the opposite of silence).
The silence is the story.
I disagree. KDE and Gnome both have pretty consistent UI strategies. You may or may not like them but they have clear identities and design guidelines and follow them.
WPF was atrocious from the beginning and Microsoft absolutely did the right thing by not basing everything in Windows on it.
Every WPF program was laggy and took ages to even start up (is everyone forgetting hard disk speeds?), partly due to it being managed code. The components didn't feel native either, and the coupling to managed code and garbage collection basically ensured all those would be perpetual issues. Yeah the programming model was beautiful and all, but you're supposedly developing to make your customers happy, not to make yourself or computer scientists happy.
You can see how terrible it would've been to base Windows's shell on WPF by looking at how much users have loved the non-Win32 windows since then.
- WinForms applications also took visibly longer to load than Win32. I didn't dread loading them nearly as much as WPF, yes, but I still did. They weren't what I'd call "snappy", but they were... usable enough.
- WinForms also stuttered (in my experience) with the GC. Again, not "snappy" in my experience, but this was more dependent on your use case.
- WinForms were .NET 2.0 rather than .NET 3.0, with fewer modules to load. It certainly felt more lightweight, which from my memory (of how the hard disk behaved) correlated with that.
I'm planing on switching over to QubesOS - way more secure (especially considering rogue LLM-agents) and visually not much worse from windows ... maybe even more cohesive.
What I find must puzzling is that everyone seems to just be violating basic rules that had been in place for ages.
Things like:
- If you can't respond to a UI event wait until you can
- Menus should be tree structures
- Pressing alt should underline the hotkeys you need to access anything clickable
As well as just basic responsiveness or predictability. A 2000 era windows application may not have been pretty, and may well have several different styles all imitated from office, but at least I knew what everything did and when it was slow at least it did what I expected.
This meant I could start the computer, log in, potentially start and use several applications and only then turn on the screen. Nowadays that has no chance of working because even to log in I need to press enter or click some button (which one depends on how I logged in previously, maybe) before I can even start typing and doing so eats a random amount of keystrokes while the damn log in screen loads to do its one damn job.
It's because we went from the Desktop environment, where rules were well-documented and standardized, to the Web/Mobile environment, where rules had to be reinvented and, for the most part, were not.
We've lost design idioms, which is a huge tax on users everywhere. I've been mad about this for years: https://essays.johnloeber.com/p/4-bring-back-idiomatic-desig...
Over the past year I've started thinking a lot more about design and UI work, and I think it's basically impossible to design things, or create design systems, that appeal broadly to different types of users in a cross-platform way.
I personally love dense UIs and have no expectation of doing certain kinds of work on a phone or low-powered device like a chromebook, phone, or bottom-barrel laptop. But if you're a company trying to sell products to a broad user base, you want to try to design in a way that works for those kinds of users because they still might be end-users of your product. And there's a good chance that those platforms may be where someone first evaluates your product (eg from a link shared and accessed on a mobile device) even for the users who do plan on using more powerful desktop devices to do their work.
So instead we get these information poor, incoherent (because it turns out proper cross-platform, cross-user design is much more difficult than just getting something that works cross-platform for all users on its surface) interfaces. I guess I'm writing this just to add, web/mobile have complicated things partially because more than just requiring their own distinct patterns, they each represent a distinct medium that products try to target with the same kind of design. But because they're different mediums, it's like trying to square a circle.
2 replies →
The rules didn't have to be reinvented - web/mobile devs chose to ignore them.
WinForms - It just works.
Any system that needs a straightforward UI for kicking things off, stopping them, logging them, and dragging data files into them..... WinForms.
Bugfree, hardened by the test of time, works on Windows X, Y and Z.
Everything else is just consumer silver sprinkles, and involves faffing around with multiple config files and obscure layout issues.
Some Microsoft managers started suppressing people who reported internal defects, instead of leveling their teams up
That sounds like Goodhart's Law in action.
1 reply →
- clicking a checkbox's label should select/deselect the checkbox
This is one that I hold my devs accountable for. No, I shouldn't have "put it in the spec", because it is the fucking spec.
We've ended up in a world where power users have been forgotten. Not out of malice, but out of a misguided aim to reduce complexity and achieve consistency with the web.
I would argue that desktop is the platform for power users, and its future depends on them. The keyboard shortcuts, the micro-interactions, the window management -- this stuff is all important when you're using a system for 8+ hours per day.
Yet we risk desktop experiences becoming less useful due to the UI becoming "dumber" as we keep shoehorning websites onto the desktop. Website UI is dumb. It's mouse driven, keyboard is an afterthought. There's no consistency, and you have to re-invent the wheel every time to get the details right (almost never happens).
>We've ended up in a world where power users have been forgotten.
I think its more like the OS vendors have stopped being operating system vendors, and are now - instead - vendors of eyeballs to advertisers.
The less the user is GUI'ing, the more they are just watching, placid, whatever else is on their screen.
For native apps to survive, they need to not be platform-specific - i.e. web apps, which require a browser and all its responsibilities - but rather cross-platform, reliable, predictable on all platforms - i.e. dissuaded from using native, but rather bespoke, UI frameworks.
This is attainable and there are many great examples of apps which are in fact, old wheels not re-invented, which still work for their particular user market.
I have the most respect for apps I can use on MacOS, Windows, and Linux - with the same hotkey/user experience on all platforms, equitably - and the least respect for apps which 'only run on one of them', since that is of course nonsense in this day and age.
The cognitive load of doing a web app that can do all the things a native app can do, is equivalent to the load required to build a cross-platform app using native frameworks, so ..
12 replies →
Mozilla removed a lot of power-user features and customization from Firefox claiming that their telemetry showed that few users used them. That's the reality now, nobody wants to develop and maintain things for the 1%.
13 replies →
> We've ended up in a world where power users have been forgotten. Not out of malice, but out of a misguided aim to reduce complexity and achieve consistency with the web.
Power users are less susceptible to suggestion and therefore less profitable. They have largely moved to OSes that do not interfere with their wishes, allowing them to make their own choices about what they can or can't do/run (Eg. Linux).
This resonates deeply. I build native macOS apps in Swift/AppKit and the difference in keyboard-first design between native and web is night and day.
On macOS, if you use standard NSResponder chain and menu items properly, you get Cmd+Z undo, text field navigation, menu bar keyboard access, and accessibility basically for free. The framework was designed around the assumption that users would become experts.
Web apps actively fight this. Every Electron app I use has broken Cmd+` (window cycling), inconsistent text selection behavior, and that characteristic 50-100ms input lag that you stop noticing until you switch back to a native app and remember what "responsive" feels like.
The sad irony is that making a power-user-friendly desktop app is actually less work if you go native, because the frameworks already handle the hard parts. Going web means you have to manually reimplement every platform convention, and almost nobody does.
I know this isn't really your main point but I don't think they've been trying to reduce complexity but rather increasing ease-of-use for the end-user*. Those things are often completely at odds with each other in software as I'm sure you know.
*well, that seems to have been their goal in the past; nowadays it just seems like they've been trying to funnel windows users to their other products and forcing copilot into everything.
If you become a power user you realize that nothing matches the power of the command line. And at that point you also realize that are better OSes that allow you to fully explode the true computing power that is terribly limited and constrained by a GUI.
2 replies →
The issue is that everyone wants a full-featured remote with only "on, volume, and channel changing" buttons.
> We've ended up in a world where power users have been forgotten.
I think the world changed. "Power users" in the traditional sense use Linux and BSD now. Microsoft and Apple dropped them when they realized how lucrative it would be to dumb things down and make computers more like cable TV.
I'm planning on writing a desktop (I've wrote about some of my goals here before) precisely for this reason
> Not out of malice, but out of a misguided aim to reduce complexity and achieve consistency with the web.
The web is not consistent itself. Lots of sites, and most web apps, invent their own UI.
This is why, for me, year of the Linux desktop was 2008. It's been atrocious since then.
In the future it will all be done by AI, no need for GUI. Just write or say what you want to do
Hopefully /s
Well, Alt+Tab in Windows is supposed to switch windows. That's unless you're in Microsoft Edge where obviously, it switches tabs. Inconsistent and annoying.
Android and Chrome worked like this for a hot minute too. I assumed the idea was to promote webapps to look like they're first-class citizens, but in practice it's just bizarre and confusing UX.
Browser tabs are the fault here and browsers are trying to be OS environment, so Alt+Tab is useful for major task switching. I agree it's inconsistent and annoying, but I like Alt+Tab as a way to try to find the window I'm writing that email to someone.
I hate this too. You can turn it off. In Settings, go to System->Multitasking and change "Show tabs from apps when snapping or pressing Alt+Tab" to "Don't show tabs."
1 reply →
Because everything got made for smartphones and touchscreens while desktop users are left to suffer in the mediocrity.
> This meant I could start the computer, log in, potentially start and use several applications and only then turn on the screen.
I mean... well... responsiveness matters to me too, and I am impressed by such inspired productivity, but... I'm also confused. Why not turn on the screen - the monitor, right?
Now thinking about how gui lag might impact the sight-impaired, tangential as that is...
It was meant as an example, not a productivity tip ;-)
Anyway the real point is that it's just easier to use something if you don't need constant visual feedback. Being able to use something blind is more than just an accessibility issue it is just better in general.
> WPF was good
As someone who saw what impact WPF had on average users running average hardware in the late 2000s to early 2010s, I disagree.
In 2011, my brother was in seminary, using an average Windows Vista-era laptop that he had been given in 2008. When he was home for Christmas in 2011, we were talking about his laptop, and he told me that the Logos Bible software ran sluggishly on that laptop. He said something about how, for reasons unknown to him, the current version of Logos required advanced graphics capabilities (I forget exactly how he phrased it, but he had learned that the slowness had something to do with graphics). Bear in mind, this is software that basically just displays text, presumably with some editing for adding notes and such. At the time, I just bought him another laptop.
A few years later, I happened to read that Logos version 4 was built on WPF. Then, remembering my brother, I found this Logos forum thread:
https://community.logos.com/discussion/6200
This shows that Logos users were discussing the performance of Logos on machines with different graphics hardware. For a program that was all about displaying and editing text, it shouldn't have mattered. WPF had made a bet on then-advanced graphics hardware for reasonable performance, and that was bad for these users. And that's just the one example I know about.
"WPF had made a bet on then-advanced graphics hardware for reasonable performance, and that was bad for these users. "
OTOH WPF is today surprisingly strong GUI platform if you just want to get your Windows GUI out there.
It runs really nicely even on low end hardware. All the nice styling and blending techniques now _just work_ even on the most cheap low end laptop.
The fact it's over decade old means all the LLM:s actually know really well how to use it.
So you can just guide your LLM to follow Microsoft best practices on logic development and styling and "just add this button here, this button here, add this styling here" etc.
It's the least annoying GUI development experience I've ever had (as a dev, non-designer).
Of course not portable out of the box (avalonia is then the ticket there).
If you want 3D, you can just plug in OpenTK with OpenGL 3.3. Decades old _but good enough for almost everything_ if you are not writing a high perf game.
Really, WPF plus OpenTK is a really robust and non-surprising development platform that runs from old laptops (eg. T14 Gen 2 per my testing) onwards.
I've been doing a sideproject using WPF and OpenTK - .net works really great - here is a sample video of the whole stack (from adashape.com)
https://youtu.be/FM_iuB3-0aA?si=j7kS68ZVenmPwvAO&t=34
I had the misfortune of writing a complicated WPF app from scratch circa 2010-2011. Performance using the WPF widgets was terrible compared to HTML/Javascript/Blink; we ended throwing away most of the WPF code other than the main shell and a few dialogs, reimplementing the importantant stuff with immediate-mode Direct3D/Direct2D to get the necessary speed.
I recall wasting a lot of time staring at decompiled .NET bytecode trying to understand how to work around many problems with it, and it was clear from the decompiler output that WPF's architecture was awful...
It goes back pretty far. Nowadays the controversy is electron vs native (where most windows devs would consider WPF/.NET a native option).
But if you read books from the 2000s, there was much discussion about the performance overhead of a VM and garbage collected language; something like WinForms was considered the bloated lazy option.
I’m sure in a few years computers will catch up (IMO they did a while ago actually) and Electron will be normal and some new alternative will be the the bloated option - maybe LLMs generating the UI on the fly à la the abomination Google was showing off recently?
FWIW Apple has made a similar transition recently from the relatively efficient AppKit/UIKit to the bloated dog that is SwiftUI.
What have you heard about SwiftUI being bloated?
3 replies →
A notable example I remember from around 2010 was when Evernote dropped WPF, supposedly due to blurry text issues but probably also performance (remember when we called it EverBloat?)
Can't find the original blog post about it but here's a couple mentions of it:
- https://www.edandersen.com/p/evernote-has-no-patience-drops-...
- https://www.reddit.com/r/csharp/comments/x0nu7h/comment/im9k...
Blurry fonts was my main issue with WPF. I get headaches from blurry text and the colour bleeding from ClearType just makes the headache worse.
Fortunately for me, I had mostly switched to Linux by that time already, where it was at the time relatively easy to just enable grey scale AA with full hinting.
In recent years this has gotten worse again with modern software incorrectly assuming everyone has a High DPI monitor. My trick has been to use bitmap fonts with no AA, but that broke in recent versions of electron, where bitmap fonts are now rendered blurry. So I had to stay on an old version of vscode from last year, and I will be looking to switch to another editor (high time anyway for other reasons).
1 reply →
WPF originally had two major rendering issues. One was the lack of pixel snapping support, and another was gamma correction issues during text rendering, particularly for light text on a dark background (due to an alpha correction approximation, IIRC). The two combined led to blurry text in WPF applications.
These were finally improved for WPF 4, since Visual Studio 2010 switched to it and had a near riot in the betas due to the poor rendering in the text editor.
I would argue that was less that WPF was the wrong life choice and more that Microsoft shouldn't have bent the knee to Intel's antitrust push to say their crap hardware was sufficient. [1]
[1] - https://arstechnica.com/gadgets/2008/03/the-vista-capable-de...
Your argument presupposes that we should accept escalating baseline hardware requirements as good or even necessary, for a desktop computing world that was, from the user's perspective, doing pretty much the same thing as before. I reject that.
Apple had been doing GPU-accelerated GUIs since the early NeXT days; it was certainly possible on hardware weaker than what Vista required.
10 replies →
> Bear in mind, this is software that basically just displays text
Displaying text is surprisingly hard, as one can easily find out if ones dives into the big rabbit hole of font rendering.
Yes, text shaping and layout are complex. My point is that the program wasn't doing anything that should have required a GPU, particularly for the resolutions that were common back then.
2 replies →
Hmm doesn't that sound like Apple's Tahoe/iOS 26? Effects upon effects upon more effects.
Not really. Ironically, WPF designers wanted to make things better by offloading the rendering onto the GPU. They also added DirectWrite that was supposed to provide high-quality text rendering with all the bells and whistles like layout for languages with complex scripts, in hopes of eventually offloading the text rendering as well.
But they just plain failed to execute well on this idea.
iOS 26 runs surprisingly smooth on my iPhone 12 Pro Max though.
2 replies →
2008 edition of “let’s rewrite it in react”.
2008 had its own version of React and it was called Adobe Air
1 reply →
The fact that software to show the bible needs a GPU is funny in some kind of dystopian way. That is the kind of software that should work in 50k of memory.
The deeper problem is that Microsoft keeps trying to solve GUI consistency at the framework layer instead of the design system layer. WinForms, WPF, UWP, WinUI -- each one a new framework, each one eventually abandoned.
Apple solved this by treating the design system as the product and letting the framework be invisible. Microsoft has it backwards every time.
> The deeper problem is that Microsoft keeps trying to solve GUI consistency at the framework layer
I really don't think that's the fundamental issue.
TFA points out, and I agree, that the fundamental issue is political: competing teams across different divisions coming up with different solutions to solve the same problem that are then all released and pushed in a confusing mishmash of messages.
I haven't written a line of code for a Windows desktop app or extension since early 2014, when the picture was already extremely confusing. I have no idea where I'd begin now.
My choice seems to be either a third party option (like Electron, which is an abomination for a "native" Windows app), or something from Microsoft that feels like it's already deprecated (in rhetoric if not in actuality).
It's a million miles from the in the box development experience of even the late zero years where the correct and current approach was still readily apparent and everything you needed to move forward with development was available from the moment you opened Visual Studio.
There's just so much friction nowadays, starting with the mental load of figuring out the most acceptable/least annoying/most likely still to be supported in 5 - 10 years tech to use for solving the problem.
Honestly, things like Electron are quite literally the problem!
All of people’s modern desktop woes begin and end at the browser. Here’s why: the late 2010’s push into the cloud made JavaScript all-the-rage. A language the creator made in pretty much a weekend coding session.
There naturally is major business incentives powering this. SaaS made things MUCH easier for delivering software.
Fast forward 15 years and MSFT is full in on TypeScript. It’s a disease that starts with MsOffice and percolates to the whole OS (same as what’s happening in copilot).
.Net is actually elegant in many ways. You have PowerShell, VB .Net, C#, F# etc. languages of many paradigms all targeting the same bytecode (and supported by the OS).
And this is being replace by a fun little JavaScript thingy.
6 replies →
Being a 70's child, in computing since the mid 80s you made me almost spill my Monday coffee.
What a laugh, do you want the examples on Apple's side?
I mean Cocoa and SwiftUI are more consistent in the sense that a lot of stuff automatically adapts when Apple changes styling. And they certainly have less churn and more focus compared to Microsoft.
Basically it's been Objective-C and Cocoa since around 2000, later on Swift and then also SwiftUI. That's not too bad for 25 years.
And in contrast to MS, you didn't get abandoned when you were sticking to the official frameworks. Quite contrary, you basically got the switches from PowerPC to x86 to ARM almost for free for example.
Apple is not perfect by any means, but in this regard I truly think they are ahead of Microsoft.
14 replies →
The evergreen question of "how do you go back and/or close an app on IOS?"
27 replies →
You can't just take 40 years of Win32 apps and add the Metro design language, touchscreen compatibility, or dark mode system-wide. WPF nowadays has a skin that imitates WinUI, so at least Microsoft is trying.
Sure, but you could have had a uniform design language for the last 3 or so frameworks.
Right, but you can make basic adjustments to the theme to fit the rest of the system better, which took them all the way until Windows 11 to realize.
The deeper problem is that all these layers are still in use somewhere within Windows. Try to give your Ethernetcard a fixed IP Address for example. On your way to the correct setting (which has visually looked that way when I was still going to school) you will move through maybe 3 or 4 layers of UI paradigms like a freaking media archeologist. Each of the newer layers dumbed things down and kept the old thing as a fallback.
Meanwhile in MacOS they dumb things down without a fallback.
The only people who appear to make serious attempts at improving the usability of computers are the likes of KDE and other Linux desktop environments. It used to be the way that Linux was the thing you used despite its shortcomings compared to commercial OSs..
I agree. Except that WinForms has not been abandoned. In fact, it's one of the supported paths in the modern .NET stack.
It lacks hardware acceleration.
1 reply →
WinForms is a layer built on top of raw Win32. So it's not portable.
Even though Wine exists, Win32 calls can only be made from Win32 programs, not native Linux programs. So a WinForms app using the latest dotnet would need to run the Windows version of dotnet under Wine, and not use the Linux version of dotnet.
5 replies →
> Apple solved this
This comment written before Tahoe
Snide and subjective comments aside, you’ve clearly missed their point.
Even if you take away subjective opinions on Liquid Glass, the point is that the core system updates things across the board.
Unless apps have implemented custom drawing, you get a consistent-ish UI (for better or worse) across the system, whereas with windows you are beholden to whatever hodge podge of UI frameworks were chosen at the given time.
5 replies →
Insightful comment
2 things Microsoft failed to do in the last 15 years are:
1) They abandoned their mobile phone, tablet, and wearable strategy. So, today if you develop a native Windows application, it will only work on desktops and laptops. That is it. It is not attractive for a developer to learn a whole new UI framework just to target a single form factor. And I don't know if there is any solution for this at this point, they shouldn't have completely abandoned those markets.
2) They did not back 1 UI framework for a long time (I mean 10 years+), instead they did significant changes to their UI framework strategy every 3-4 years. It takes a huge time for developers to trust, learn and develop complex and polished apps in a UI framework. Also it takes a long time for a UI framework to become mature. If you change your UI strategy every few years, you will never have complex and polished apps written with it.
To be honest I am not sure if Windows will ever be able to recover in the long term and keep its market share. The only reason it seems to be alive is because enterprise runs on Windows and it is hard to change that.
I feel like an Apple + Google dominance will be more likely in the long term for desktop operating systems. I am not sure if Google will be able to avoid the first mistake I wrote above but they are working on bringing Android to desktop. It is a good idea but it requires at least 10 years of supporting and polishing it despite not getting much traction. But if Google persists, we might be all using MacOS and Android on desktop 20 years from now.
Yeah, a striking difference between windows and linux at this point is that the linux UI frameworks are hyper stable. If I want to make a linux desktop app, I'll choose QT or GTK. Heck, if I want to make a windows and macOS app, I'll probably choose QT or GTK.
What do I chose with Windows? Who knows. It literally changes every time I look into it.
That's just insane.
It's gotten so bad that probably the right way to do a modern windows desktop app is react native. At least you could predict that it will stay up to date with the ever shifting decisions at MS to create and abandon UI frameworks.
Windows Forms is the answer you seek. It still receives updates to this day. I've been writing and shipping Windows Forms apps for 25 years. High DPI, dark mode, Edge web views, Blazor integration, we've got it all. Users don't even need to install .NET these days with self-contained deployment.
I will boldly claim Windows Forms is more stable than Gtk and Qt. Don't let random teams at Microsoft confuse you because they released yet another unrelated framework that you don't have to use. They are engineer-sirens trying to lure you from the true path. Let them pursue their promotions in peace while we rely on a stable workhorse.
On Windows, I would chose WinForms. Even today, even over WPF. It's as stable as QT and GTK, still supported, and has a large community of contributors and 3rd party vendors.
win32 seems to be stable, albeit a bit dated. It's good enough for small things (at least good enough for m$ to use)
2 replies →
GTK 2, GTK 3, or GTK 4?
1 reply →
Strong agree!
They had great devices before iOS/Android and then again after. That Lumia phone was awesome. They had one of the best cameras. Their live tiles they had on the phone & desktop OS were really good. Even Windows 8 had a cool CRM app in its infancy that tried to link all your social media & email accounts together.
They killed all of that even with multiple chances to win people over. It seemed they wanted to win the new markets in less than a year.
For as much flack as Google gets for short lived awesome products, Microsoft is right up there. Which is why when they've announced new things like Blazor, MAUI, etc., no one expects them to live long enough to trust their apps on.
I also strongly question their enterprise MOAT when most kids are growing up on Apple & Google devices the past decade. Microsoft seems to lack long term strategy.
> They abandoned their mobile phone, tablet, and wearable strategy
They were way too late to make a dent. Ballmer made the mistake when the iPhone came out to not get their ass in gear to compete. Microsoft's first potential real competitor to the iPhone came with Windows Phone 7 at the very end of 2010. The iPhone was announced in January 2007 and they didn't have anything to compete until almost 4 years later. I'm not sure how they could have recovered from that by the time they gave up on Windows Phone/Mobile in 2017. Anyone who worked in mobile sales at that time knew most people who did buy a Windows Phone ended up returning it when they realized none of their apps were there. They could have had apps if they recognized the iPhone's threat earlier and reacted appropriately.
Also worth mentioning that in their time competing for mobile they did a fairly hard reset of the platform 2 more times for Windows Phone 8 and Windows 10 Mobile. Go find what developers who tried to keep up have to say
https://news.ycombinator.com/item?id=15432720#15434572
totally.
MS ended up where it was at because there was basically NO upgrade path between the few different GUI frameworks they had. They broke the whole thing in 2002 when they decided .NET was the way.
You had to basically retool your whole GUI for whatever they were pushing at the time. Then they basically abandoned win32 GUI items and put them in mothballs. Then change their minds every other year.
No sane person is going to pick that model of building an application. So the applications kinda stagnated at whatever GUI level they came into being with. No one wanted to touch it. If I am doing that why am I sticking with windows? I can get the same terrible effect on the web/mobile and have a better reach.
Even their flagship application windows is all over the place. If you click on the right thing you can get GUI's that date back to windows95. Or maybe you might get a whitespaced out latest design. It is all over the place. It has been 10 years at this point. They should have that dialed in years ago.
I do not think Google will be able to pay attention long enough to have a stable GUI. Apple maybe. As for MS you can see it from the outside there are several different competing groups all failing at it.
MS needs another 'service pack 2' moment. Where they focus on cleaning up the mess they have. Clean up the GUI. Fix the speed items. Fixup the out of the box experience (should not take 4gig of used memory just to start up). Clean up the mountain of weird bug quirks.
Didn't Google give up on chromeOS? For all their faults, at least Microsoft has a desktop os
I remember when ChatGPT exploded and Bing had it integrated, the idea was brilliant because unlike ChatGPT it didn't have information cut-off since it can access the web. I was very excited to ditch Google for AI chat with web access.
How did MS actually implemented it though? After a few messages the chat is blocked because MS did not choose to walk the extra mile and maybe compact the context so that their product can be actually usable.
Of course OpenAI, Perplexity and others later implemented that properly and its integral part of modern AI chat and I actually ditched Google for the most part. Had Microsoft done it, they might have had a shot in replacing Google and maybe becoming the AI Chat provider. But no, Microsoft can't have a well thought UI to provide a delightful UX.
IMHO it's a culture thing. Lack of cohesion is a result of it, I used to be annoyed by Apple that doesn't allow to ship its own UI libraries together with the app so to support old versions etc. but Apple had it right, thanks to the limitations UI is coherent.
> Apple that doesn't allow to ship its own UI libraries
You can just render on a canvas like flutter and KMP. Most end users don't care
There’s a poster on here who keeps posting and re-posting about their dinner with a Microsoft executive and how they were told Microsoft is all-in on enterprise. Waiting for that copy-paste to make its way over here.
Microsoft keeps footgunning things so hard I think even enterprise might be reluctant to go with them moving forward [0]. I don’t have Netcraft numbers in front of me but I doubt things have notably improved even if they do have a strategy shift to enterprise which includes crapping all over Windows for no good reason.
I’m personally glad FOSS is going strong but that’s a complete aside.
[0] We got burned by Azure as I’m sure many other enterprises have, and they did exactly nothing to remedy/compensate the situation, SLAs be damned. At this point our strategy is to move off of reliance on any Microsoft/windows tech. We moved off of ActiveDirectory not too long ago. Bing/Edge/etc honestly who cares.
Microsoft was so focused on the enterprise they forgot that enterprises are made up of individual users.
Any trade-off that favors the enterprise in lieu of the user actually benefits nobody in the long term.
Crucially, at enterprise sales, those who make putchase decisions are not the actual users (except maybe for Outlook and Excel). They sometimes play golf together with vendors though. This is how stuff like MS Teams of Oracle Forms gets sold: it checks all the compliance boxes, has support, an SLA, "is industry strength", etc.
1 reply →
The end state of genAI is that the end user is the enterprise
6 replies →
Desktop, especially Windows, is such a mess.
It's 2026. We're running 8+ cores and 32gb ram as standard. We can run super realistic video games at high frame-rates.
Yet on the same machine, resizing a window with rectangles in it is laggy on every platform except macOS (where there's a chance it's not laggy).
The bloat is pretty incredible. Consider my Amiga 500 could resize windows without lag on a ~7.1 mhz 68000 and 512K of RAM, almost 40 years ago.
Resizing was based on a wireframe system and windows weren't repainted during resizes.
1 reply →
4-6 cores and 8GB standard* 8 Cores and 32GB+ is the higher end.
imo the resizing test is not useful because it's a useful test of a common operation that needs to be optimized, but because it flexes on every major subsystem of the GUI framework.
Another example is startup time. Time to first frame on screen should be less than 20ms. That doesn't mean time until first content is rendered, but time until _all_ content is rendered (loading dialogs, placeholders, etc are better than nothing but entirely miss the point of being fast).
The second example is why even though I understand why developers pick tauri/electron/webviews/etc I can't get over how fucking slow the startup time is for my own work. None of them could show a blank window in under a second the last time I tried.
Sorry but neither Linux or Windows lag to resize windows in any of my 4 machines.
They range from old laptops to a Ryzen 7 9800X3D workstation.
Just yesterday a friend's father needed help setting up their second-hand old laptop with an old i5 processor. I slapped KDE and there was no lag to be seen.
Bonus point that Windows and some Linux distros have sane, intuitive window management. Whereas with macOS I keep seeing someone suggesting some arcane combination of steps to do some basic things with replies to the effect of "OMG thank you so much, this needs to be known by more people!!!"
I see frame drops when opening the start menu on a clean Windows 11 install on my work laptop (Intel Quad with 32GB memory from two years ago). I have seen the same on 3D Vcache Ryzens on systems from people who claimed there was not lag or sluggishness. It was there and they saw it once pointed out, the standards for Windows users have simply gotten so low that they’ve gotten used to the status quo.
On MacOS, meanwhile, Finder refuses to update any major changes done via CLI operations without a full Finder restart and the search indexing is currently broken, after prior versions of Ventura where stable functionality wise. I am however firm that Liquid Glass is a misstep and more made by the Figma crowd then actual UX experts. It is supposed to look good in static screenshots rather than have any UX advantage or purpose compared to e.g skeuomorphism.
If I may be a bit snarky, I’d advise anyone who does not see the window corner inconsistencies on current MacOS or the appealing lag on Windows 11 to seek an Ophthalmologist right away…
KDE and Gnome are the only projects that are still purely UX focused, though preferences can make one far more appealing than the other.
If we're talking a simple "hello world" window then sure, you can resize that at 60fps on pretty much any system.
But most nontrivial apps can't re-layout at 60fps (or 30fps even).
They either solve it by (A) allowing the window to resize faster than the content, leaving coloured bars when enlarging [electron], or (B) stuttering or dropping frames when resizing.
A pleasant exception to this I've noticed is GTK4/Adwaita on GNOME. Nautilus, for me at least, resizes at 60fps, even when in a folder of thumbnails.
On the Mac side, AppKit, especially with manual `layoutSubviews` math easily hits 60fps too. Yes it was more complex, but you had to do it and it was FAST.
1 reply →
My work laptop will stall on resize constantly, and I suspect it is due to the mess of security and backup software. Windows does have an ecosystem problem.
I am also baffled by the multiple control points. I can log in to mail in 3 places. Settings have 3 with different uis....it is gross.
I used to be a software test engineer at Microsoft in the late 90's and early 2000's. What I learned is that 60% of their business was International because of their language support. Also most of their customers are business customers locked in to using their Windows Server Domain system for corporations. These corporations also run office and Sharepoint and build custom apps using office. This is why they have so many different ways to build apps on Windows. We are not the users they are targeting, they target the enterprise.
Java wanted to run your code everywhere so they basically wrote a byte code compiler and then wrote one vm per OS/architecture
I never understood.NET's purpose. What problem it exactly went out to solve? Did Microsoft want developers to be able to run their applications everywhere too? Absolutely not.
Sidenote - MFC is the ugliest thing you'll see. Yet they didn't mention another piece of work called ATL. Active Template Library.
WinForms were really decent and that was enough. Keep Win32 API and a managed wrapper around it as WinForms and that would have been more than enough.
.
FWIW, x86 has always been a pretty moving target with many instruction set extensions, especially for various SIMD features. But even something fundamental like `popcnt` has a separate CPUID flag, even though Intel considers it part of SSE4.2.
Targeting the broadest possible variant of x86-64 limits you to SSE2, which is really not very capable outside of fairly basic float32 linear algebra. Great for video games, but not much else.
Also keep in mind that .NET originated right at the cusp of x86-64, which again is a whole different architecture from its 32-bit predecessor. Most native apps used to ship separate binaries for years.
And of course, I think Microsoft was aware of their intrinsic dependency on other companies, especially Intel. I can see how the promise of independence was and is enticing. They also weren't interested in another dependency on Sun/Oracle/whoever maintains Java at the moment. While Windows on ARM64 is still in a weird spot, things like .NET are useful in that transition.
Lastly, the CLR is different from the JVM in a number of interesting ways. The desktop experience with the JVM is not great, and Java is a very bad language. It makes sense to do your own thing if you're Microsoft or Apple.
I doubt that .NET was meant to solve the problem of underlying variation in instruction set of Intel processors because that concern does not exists for 98% of the applications anyway they rarely have to look for the compiler settings and for the rest of the 2%, the compiler flags are huge set of options and that kind of tweaks are NOT available for .NET anyway.
Additionally, such applications that want to exploit certain underlying processor's instruction set have no way to do so without detecting CPUID and landing into so called "unmanaged code" because .NET is all about very high level IR that even has object oriented features as well.
3 replies →
> What problem it exactly went out to solve? Did Microsoft want developers to be able to run their applications everywhere too? Absolutely not.
So .. initially it was "Microsoft Java", a managed language with tight integration into the Windows APIs, and non-portable. That was .NET Framework. A while ago they realized that even Microsoft didn't want to be tied to one platform, and moved to the cross-platform ".NET Core". It now occupies a similar role to Java but is IMO nicer.
> I never understood.NET's purpose. What problem it exactly went out to solve?
Java. Java is the problem .NET attempted to solve.
Is MFC that bad? I'm inclined to learn it now and see it with my eyes. I dabbed into Win32 programming for a bit (really just a bit, like a few days) and it was tedious, but not really anything bad.
in its beginning .NET was a wrapper around ActiveX and Com-objects and it tried with C# to replace Java (disregarding the Virtual J++ attempt). as their own JVM did not meet the license agreement they made with Sun. so there were several reasons and not every reason being one a developer would care about
I think the answer is simple - they wanted to Sherlock Java.
For others like me that didn't know the term Sherlock:
It means "To obsolete a unique feature in third-party software by introducing a similar or identical feature to the OS or a first-party program/app." The term stems from Apple's 2002 release of Sherlock 3, which made a popular third-party app named "Watson" irrelevant.
https://en.wiktionary.org/wiki/Sherlock#Verb
WinForms still exist, still supported, still getting new features. And it's open sourced. https://github.com/dotnet/winforms
> Active Template Library
Ugh that brings back bad memories. I remember it was supposed to be the answer to MFC. I did an internship where my boss wanted me to use it. It was very painful because it had basically no documentation at all.
Wow, totally ignores the one framework Microsoft developed that was actually a pleasure to use (WinForms). Avalon sucked IMO; it was just a continuation of the fever dream at the time of making everything XML (or XAML in that case). MFC sucked because it was C++. WinForms was that brief Window of “modern programming language with simple, elegant GUI framework”.
I know it’s not a popular opinion, and I am sure there were reasons Microsoft abandoned it, but that was a brief few years when I actually enjoyed building GUIs on Windows.
WinForms apps always felt "tight" compared to all the other options (the development experience and the end product), and there were lots of 3rd party controls available. If you were building windows desktop app in the early .NET days it sure seemed like the way to go, and those apps lasting so long looks like a supporting data point.
EDIT: just dug out a "memory magic" winforms app I wrote sometime in the early 2000's and ran it no problem, no weird looking non-native UI or long electron startup...
The 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!. I use Windows every day but I almost exclusively develop cross-platform systems based on the WWW, Java, Python, etc. Whenever I have developed with .NET it has been for a cross-platform front-end like Silverlight or Unity/itch.io.
I can’t say I have a desire to make a native Windows GUI app when I could make a web app: like if it worth doing from my computer isn’t it worth doing it on my iPad from anywhere with Tailscale? For all the complaints about modern JavaScript it gives you the pieces to make a very pleasant world in terms of DX and UX and you certainly don’t need to ship an Electron runtime for many applications.
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 make sense.
Just build for the web. You can package web apps for all the major app stores using PWABuilder[0], no Electron needed. Just fast, lightweight apps distributed by app stores and accessible from the web.
[0]: https://pwabuilder.com. Disclaimer: I work on this
> 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 make sense.
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.
> 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 make sense.
You mean the hypertext platform that has been shoehorned into Java's paradigm, suffering from the same boof-o-rama as Windows, and whose lowest common denominator to support must be Safari for iOS?
5 replies →
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.
11 replies →
Because many of those features aren't Web, rather Chrome OS Application Platform, but apparently folks forgot everything about IE history lesson.
Seems to me the point of the web is: no app store bullshit.
On the web if I want to publish a web app... I publish the app. If Apple things my app isn't good for their business... tough luck for them.
If I want to update a web app... I update the app.
If a user wants to use an app... They visit a URL and the app is there! No having to face id, go looking for the app in an interface that's designed to hide the search function, that is filled with spammy trash imitation apps (that somehow get approved by the app store anyway)
All the time I hear somebody crying that their developer account got canceled and I want to say "what did you expect? the contract for a developer account is a suicide pact for your business." Stay free!
What happens when the user doesn't have internet access, or only has very slow internet? What if they're on a metered connection?
>Your post is touching on a key question: why write a Windows-specific app?
Why write an anything-specific app?
> 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?
There are other options besides "web app" and "only one OS". A cross platform app which uses something like GTK or QT will be a massively better experience for your users, one a web app cannot hope to equal.
9 replies →
Features. Speed. Do your web apps only work in Chrome by the way?
1 reply →
[dead]
Windows until 24H2 (when Edge and the last remnants of IE were replaced by Chrome) supported HTML apps [1], introduced with Windows 98 Active Desktop. They weren't used much but actually not that bad for end-user needs.
[1]: https://learn.microsoft.com/en-us/previous-versions/ms536495...
It was decent, we shipped one but switched to .net because of high dpi scaling issues IIRC
> For all the complaints about modern JavaScript it gives you the pieces to make a very pleasant world in terms of DX and UX
There is no such thing as pleasant UX in a web app. The best experience will always be a native app, a web app is at best a port in a storm solution.
When Windows wants to nag you it makes marketing-oriented screens that I think are visually attractive in a commercial way if not quite as 'cute', 'cool' and 's--y' as a gatcha screen from a mobile game. These sure look like they were drawn with an HTML-based rendering system and if they weren't, they were certainly inspired by commercial art on the web.
When MacOS wants to nag you it pops up a Liquid Glass vandalized version of the 1999 retread of the modal confirm dialog from the 1984 MacOS.
I wish both of them had NEVER OPEN A MODAL DIALOG THAT I DIDN'T ASK FOR EVER AGAIN button that took 80% of the space and a tiny little greyed-out link at the bottom that said "maybe just maybe I want to hear about this in three years" but from a graphic art viewpoint I laugh at MacOS.
> The best experience will always be a native app
Nonsense. The best experience is the one that solves user’s issue. Technology choice is orthogonal to that.
Figma is far superior to the native apps it replaced. As is VS Code. Slack.
5 replies →
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.
At this point one must ask if Microsoft is still a software platform company - whether their products form a substrate where an ecosystem can form and build a coherent software environment for the users of their platform.
Microsoft used to be the Windows company (after being the BASIC company, then the DOS company). Then it became the Office company. Now it’s SharePoint and Office365 and Azure, a utility. Windows is a relatively small part. Office is both desktop and web (and spacecraft, where they have two versions of Outlook and none of them works). If you are confused at this point, so am I. There is no vision as to what Microsoft is. If Satya Nadella knows what Microsoft is, he isn’t communicating it properly. It’s not Azure, because there is also Office and Windows. And on-prem server products. And a line of hardware products. And stores (do they still exist?).
MS has never been a software platform company. That's the fundamental reason behind the issue the article talks about.
MS has always been a software application company. Windows was never anything more than a way to sell MS applications--and Windows 3.0 and later wouldn't even have existed in the first place if IBM hadn't dawdled so long over OS/2. Even in the MS-DOS days, when MS was reaping the benefits of IBM's previous bonehead decision to hand the PC OS market to them, MS was selling Office applications--on the Macintosh.
The basic Windows API, in all of its many incarnations, has always been a second-class citizen; MS Office applications have always done their own things that other Windows applications couldn't do without using undocumented features that MS could change at any time (and often did). One could argue that the only reason MS even allowed third-party Windows developers to exist was so that they would, in the words of one of PG's essays, do market research for MS. When a third-party dev came up with something that got enough traction, MS would simply incorporate it into their apps.
4 replies →
Microsoft has always had a broad vision of itself as a technology company; I feel it's perfectly fine to not be able to describe Microsoft in one sentence without using platitudes like "empower every person on Earth to achieve more" or "put a computer in every home and every office" (both paraphrases of actual MSFT company mission statements), and I suspect many other current and former Microsoft employees would feel the same way.
IMO Microsoft's best long-lived products have always been both finished solutions to your problems and platforms to help you develop more solutions, and Microsoft leadership has always recognized this. Examples: Windows. Office. Dynamics (their Salesforce competitor).
But even if a product doesn't meet that "why not both?" ideal, there is always going to be room for it at Microsoft, as long as it is not only a good or at least mediocre product by itself, but also works to sell you on the whole Microsoft ecosystem. Sometimes that is a bad thing (see all the Windows adware for Bing, Copilot, and M365). But that at least is where Microsoft remains consistent.
1 reply →
Nadella thought he could take the reins and start yelling “Cloud! Cloud! Cloud!” and that would be successful. He doesn’t have a strategy and now that’s becoming apparent.
15 replies →
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.
Correct for the Windows 8 and 8.1 initial versions, it was already quite good with UWP on Windows 10.
But then they rioted internally to kill C++/CX (the only time they had something comparable to C++ Builder), Project Reunion got announced and misused from the original goal, porting WinRT back into Win32 killed .NET Native as well, most of the key team members left to Amazon and Google, Azure or AI teams, the team is now mostly interns or juniors from Microsoft India, no direction, and is a mess, naturally.
I went from a WinRT advocate, to pointing out devs to stay away from it, this is how bad they treated those that actually believed WinRT could be it.
The Windows Store thing was so terrible that I would argue the only good thing that came out of it was that it made Valve/Steam invest in Linux.
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?
1 reply →
Part of the reason was that WinRT was aimed at tablets and other low power devices, where unrestricted Win32 API use could drain the battery too quickly. They were trying to put the genie back in the bottle to have more control in this new ecosystem, like Apple enjoyed on iPad, etc. Much of the weird signing and app store evaluation was to make sure your app used only the blessed APIs and wouldn't, for example, stay awake in the background listening on an arbitrary port and drain the little tablet battery.
Painful and nonsensical from a desktop standpoint but also kind of impressive in a way.
My favorite example of that was when WinRT app .exe files could not be launched from the command line. Only via some Windows Store voodoo dance with approvals, signatures and "security" that made WinRT for developers essentially a dead-on-arrival technology.
I would not be surprised if you still cannot launch a fricking .exe.
1 reply →
My coherent GUI strategy: just use JUCE.
Invested in it, shipped it, seen it solve the cross-platform problem beautifully.
Can just write C++, and see it running everywhere.
The JUCE GUI capabilities are more than adequate for many, many things.
There are other platform-scaffolded cross-platform frameworks. JUCE is cromulantly FNORD.
Use JUCE as much as you like, but please, stay away from those 'out-of-the-box' horizontal sliders it seems to prioritize (given how they swarm in the many VSTs made with JUCE).
If sliders are vertical in the real world, there’s a reason for it that Bruce “Tog” Tognazzini summarizes perfectly:
“Most of us […] have our forarms mounted on a pivot we like to call our elbow. That means that moving our hand describes an arc, rather than a straight line. Demanding that pivoted people move a mouse pointer along in a straight line horizontally is just wrong.”
Source: https://www.asktog.com/columns/022DesignedToGiveFitts.html
JUCE' GUI framework is extremely versatile - if that default irks you, its a couple lines of code to get pretty much any control to behave itself.
That sounds intriguing - are there examples of desktop apps (eg productivity apps) that are made with JUCE?
I'm already very familiar with JUCE in VST plugins, I have hundreds of VSTs made with JUCE and I love their UIs. But I don't think I've ever seen it for a standalone business application?
The JUCE pricing is certainly far more reasonable than Qt.
>desktop, productivity apps
You can configure your JUCE project to build to any of the standard audio plugin formats, or for it to build a standalone app for the target platform (i.e. plugins, desktop, mobile, embedded) or indeed to build all of these targets, at once, in one build.
However, during app (i.e. non-plugin) development I often switch between linux and macos environments as part of my workflow, and during testing after I've pushed to the proper branch, the build server plops out the .exe/.pkg/.app/.tar.gz bundles as needed for the test group to crack at it.
JUCE, being at heart a C++ framework intended to be the engine of a very diverse swath of different OS, plugin, and packaging standards, does all the glue to get you there - how you use it, is up to you. (All of this can happen in github actions, btw, really easy to set up..)
Yes, there are 'business'/'productivity' UI elements in JUCE app targets, and yes they are consistent across all platforms. And yes, you can for example build a UI from an .xml form, with cross-platform datastore and so on, easily enough.
Here's a nice place to start, if you wanna understand JUCE capabilities from a 'productivity'-app perspective:
https://www.youtube.com/watch?v=3IaMjH5lBEY
David Rowland, a core JUCE developer, explaining the guts of things.
Basically, the scope is high performance applications, and there are no really good reasons for why a high performance application cannot also be a productivity app - the distinction is arbitrary - except of course you ask, for the GUI!
But: JUCE' GUI is pretty darn good, I have to say, in face of the onslaught of platform vendor fuckery. You can embed a WebView if you really need it, and wire it up to the rest of the cross-platform event handing system, etc. But I think its not really needed, given the plethora of 'normal' UI controls, out of the box.
If you're serious about looking at JUCE for a variety of application types, then a lot of the questions you're going to have about JUCE' GUI suitability for standalone business applications can be answered by running the DemoRunner application that's built-in to the JUCE codebase.
Clone the repo, build the DemoRunner project for your platform (or all of them), and you'll see - there are plenty of business-like cross-platform UI elements in the kitty. A huge collection of business-/productivity- like UI elements, right out of the box. (High-performance plugin UI's are there with the business UI stuff, too.)
And .. once you've marvelled at the glory of DemoRunner(.exe,.app,.apk)[etc.] .. please do yourself a favour and spend an extra hour parsing the awesome-juce list:
https://github.com/sudara/awesome-juce/
JUCE is marvelous, and awesome-juce is awesome.
1 reply →
Qt Small Business pricing is very reasonable.
2 replies →
JUCE has too many downsides to seriously recommend imo. "Just write C++" is also doing heavy lifting, since JUCE is its own bespoke flavor of C++.
When a platform can’t answer “how should I build a UI?” in under ten seconds, it has failed its developers. Full stop.
That's fine, except no platform answers this.
Obviously Linux doesn't, but the Mac doesn't either. Apple of course has it's recommendation, but most developers do not take Apple's recommended path because of course, it's Apple-only, most developers make cross-platform apps these days.
Even if Microsoft decreed the one-and-one Windows development path, most developers are not taking that path.
It used to be the case that Mac developers used Apple tools, Windows developers used Microsoft tools, but those days are gone. Developers want to use Electron, or Qt, or some other system to support multiple platforms in one codebase.
Microsoft has less to do with this than the article makes out. I'm a desktop developer. I don't care what Microsoft recommends, or what Apple recommends, because neither work in the real world where supporting only their platform just isn't realistic.
I think the mac mostly does this. Developers not caring about the answer is a different thing.
But I gather from your comment that you don't actually care to ask that question, since you have a different need, and already have a solution which works for you. Which I guess is fine if you're happy with the compromise.
But this is about people who actually still care to have "native" applications.
Linux can answer the question, but you're considering Linux as a monolithic platform which it isn't. If you ask "how do you build a UI for Gnome / KDE / Android?" then the answers are pretty clear.
Also, being KDE native means using QT which is a good cross platform toolkit anyways.
3 replies →
Having spent some time kicking around the Delphi space I got quite into WPF in 2007ish. By 2010 I had not just sworn off it, I'd sworn off Windows entirely. The constant stream of rug-pulls as one bit of MS managed to pull off a political heist over another and - oh no - yet another "latest and greatest" technology was effectively deprecated within 18 months of launch, invalidating all the effort you put in to staying up to date just became a pointless treadmill.
Fortunately Rails was taking off at that point so it was fairly easy to change horses and just ignore it.
If I'm writing Windows desktop GUIs I still stick to WPF. Might be Stockholm syndrome but I quite like it.
I don't see the reason to use any of the new ms ui frameworks. Especially if ms themselves don't even really use them.
As far as I know visual studio is still a WPF project so I'm not super worried about it no longer working.
WPF looks much nicer. Personally I find it hard as hell to debug.
Winforms just work, and have a well defined set of behaviors. It does not matter that they do not look as nice for most people.
That’s not so bad. I still stick to win32
Microsoft had a lot of great talent suffering from a lack of leadership and coherent vision. They foreshadowed everything wrong with Big Tech today.
what surprised me is how different the rendering architecture is for each framework.
Win32 -> message loops & GDI
Winforms -> managed C# via P/Invoke
WPF -> throwse all away and uses DirectX
UWP -> Appcontainer sandboxing
WinUI -> decouples from OS entirely
This visual breakdown helped me to see it clearly - https://vectree.io/c/evolution-of-windows-gui-frameworks-fro...
1 reply →
At the same time VB still works and runs, so they don't always rug pull.
They might have forgotten to pull that rug.
2 replies →
Steven Sinofsky wrote this piece a couple of weeks ago about the same topic:
https://x.com/stevesi/status/2036921223150440542
I've read this and the relevant chapters on his Substack and I think I get the idea that he tried to implement, but it's obvious in 2026 where his vision diverged from what people really wanted.
In the ideal world, Win32 applications would have automatically run in a sandboxed WinRT environment with granular permissions. A program thinks it's accessing a USB webcam, but it is actually accessing a Win32 shim that goes to the WinRT that first prompts the user to obtain the necessary permission and then goes to the real Win32 USB API to interface with the camera. A program is trying to access a file that hasn't been selected in the "Open file" dialog or dragged into it or passed as a command line argument? Raise a "malicious access" warning.
Overly complicated programs like antiviruses would have been able to get a "hall pass", either by registering their builds with Microsoft or asking for an administrator-level exception.
Of course, this would've been terribly hard to implement. Doing it natively would be supremely complicated, much harder than just designing a whole new userland API like WinRT. And sandboxing every application in something similar to Sandboxie would've been too taxing on the PCs from that time.
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 on scorching all the ground that wasn't theirs. My team actually did some prototyping for Python/WinRT support, and we had it working to the point of the visual WPF designer in Visual Studio even. Unlike JS, it was full fledged - you could use anything in WinRT same as C#, extend classes etc, while JS limited you to a "consumer" surface of the API. That prototype was killed because Windows (i.e. at the time = Sinofsky) said they didn't think developers cared about anything but JS so they didn't need another high level language.
It was also when Windows was aggressively pushing their Metro styling on everything in the company, sometimes to ridiculous lengths - e.g. Visual Studio at the time "aligned" with Metro by, I kid you not, making the main menu bar ALL UPPER CASE so that it looked like Metro tabs! You can still see the blog posts announcing this "feature" when it shipped in the first public beta of VS 2012, and the comments on them.
And then there was Windows RT (not to be confused with WinRT, because Microsoft product naming!). Aka the Windows-on-ARM that ditched decades of backwards compatibility because Sinofsky decided that rebooting the ecosystem is the only way to compete with iPad or whatever. What actually happened was that the users went WTF because none of their native apps - which, contrary to his take, were very much alive and kicking! - worked there, and devs went WTF because they were told that they'd need to rewrite everything yet again in some new thing that was kinda sorta but not quite like WPF, because Windows just hated .NET that much and couldn't accept that the devs liked it over their stuff. So the app store was a barren waste, and without apps there would be no users.
Some of the technical details in there are plain wrong, too. For instance, .NET 3.0 actually shipped in Vista, contrary to his claim that it was shipped in Win7 (and that it was the first time .NET shipped in consumer Windows - in fact, that would be .NET 1.1 shipping in WinXP SP1).
Sinofsky kept talking about how many devs were making apps in JavaScript and how they would just be at home in Win8. This was before React, ES5 (no native classes! or promises!), etc- jQuery was still very popular and SPAs were extremely rare. He completely overlooked how dependent many of these devs were on their servers- Python, Ruby, PHP, etc.
1 reply →
Often kind of person who makes such mistakes is the kind of person unable to learn from them. The post by Sinofsky is exactly as I imagined it would be.
> 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.
Yeah, he's talking about WinForms like it was a whole new thing, but it was a very transparent OO layer over Win32 and extremely similar both to VB and Borland Delphi. It was one of the reasons why .NET survived at all when Linux servers became the default option.
(disclaimer: I was an individual engineer in the Windows division during the Windows 8 project, i.e. reporting through Steven Sinofksy)
I think you're being a bit unfair to the Windows division during the Win8 lifecycle. Maybe that's just my rose-tinted glasses though. I know there are some HN/proggit commenters who like to harp on the supposed toxic rivalry between the Windows orgs and Microsoft developer tools orgs and how it has made Windows' developer platform much worse over the years, but I have always thought we had a better relationship than that, since my group's product was the main reason for yours for many years, and your group delivered so much for us in turn. Clearly your side had at least some reason to see things differently. On behalf of all of us, yes even up to stevesi, I'm sorry.
Now let me completely undermine my apology by nitpicking your comment :)
[continued in my replies to this comment]
5 replies →
I have always been tempted to use WPF but I’m reluctant to learn a whole new language for side projects. Especially nowadays C# seems to be as huge as C++. Oh well maybe I should grit through the beginning phase.
How is he dunking on .net?
I think one of his main points is server .net was (and is) great.
But the UI part of it was cloudy.
I see it as complimentary to the post not contradicting it.
2 replies →
> making the main menu bar ALL UPPER CASE
I remember that. Especially silly.
> Windows RT (not to be confused with WinRT, because Microsoft product naming!)
The gold standard will always be "Xbox one series X", designed to be confused with Xbox one series S.
Windows RT had one other anti-consumer and anti-developer feature: it was locked down like a Chromebook, so you could only use Store apps on it.
2 replies →
It seems Windows division has too much power and they used it to break their things.
Also, Windows division is shipping a subpar product now.
In a sane world developer division and Windows division would think things together, developer division would produce the tools and the same tools would be used by Windows, other Microsoft products such as Office and third party developers.
Why that doesn't happen at Microsoft, I don't understand.
And I don't understand why Nadella doesn't do anything about it.
1 reply →
Since that article is a response to this one, we'll add a link to it in the toptext above. Thanks!
Thank you!
Is there any way to get to the article without going through x.com? xcancel.com just says "Nitter doesn't support this feature yet, but it might in the future."
Fun and sad. Garbage collected languages like .NET, Java, and Go are slow compared DIY languages like C, Rust, and Swift. So, no wonder the Windows team dislike them. However, it seems the Windows team had to live with a React start menu for quite some time. How does that fit into the over all battle between the teams and UI frameworks?
That wasn't the issue. The problem was that most of Windows system utilities are not managed, but the WPF move was trying to make a patchwork quilt of managed vs. unmanaged utilities, making the entire system very difficult to reason about and introducing regressions constantly. From the Windows Team's perspective, the .NET people just made a mess out of everything they touched.
Perhaps if WPF really did stay at the presentation level, or used VMs or something to keep it away from the Windows core, it would have panned out better. But is it goes with "paradigm shifts", when a company thinks it has a great idea, it wants to suddenly do that great idea everywhere.
The answer is, clearly, Qt.
(This isn't even a joke. Assuming you're not going Electron.)
Part of the reason here is that it's their main business. They can't afford letting it languish and/or changing direction every 6 months.
Which one? The classic QtWidgets, which implements consistent controls but sometimes talked about as deprecated (same as WinForms), or QML, which is "modern" and "actively developed" but does not provide native look and feel and requires (or at least used to require) a lot of manual work to support proper keyboard control and accessibility?
The biggest issue in my opinion is that Microsoft is chasing web devs. XAML is pita, just like css and html markup. They need to pick a lane and just use it. Allow other frameworks access to the default low level api such as Win32, but document it to the same level as Google does on Android and Apple with SwiftUI
I actually like the idea of GUIs being represented in a markup (whether that be XML, QML, GNOMEs new Blueprint (which is kinda a markup language I think?) but I also thought display postscript was elegant so maybe I'm backing the wrong horse
I think the whole world sails on that ship and MSFT just wants to catch up. Their most darling developer tools since 10 years ago are mostly by web and for web: Typescript, VSCode.
I remember I was trying to learn GUI programming in late 2000s. I took an attempt at MFC but no matter how hard I tried, it just didn't make any sense. Then I found out about Qt 4 and it felt like magic immediately. I ended up working as a professional Qt software developer for 3 years.
Fast forward to now, and KDE Plasma is state of the art Linux desktop that I've been daily driving for years. It's also built on Qt.
As of today, I only use 2 solutions for Windows GUI :
- windows forms in .net
- flutter
All the rest always presents itself with a sheer aura of "It was a great idea but we couldn't finish it".
Without ever discussing with anyone from MS about it, I think they stopped improving/working on this because of electron.
Any web developer can build a good enough website and a good enough desktop app with electron.
This barely mentions Windows Forms, which is the cleanest and fastest way to code Windows GUI apps.
A few years ago, I wanted to prototype something quick and I wrote it in Windows Forms over C# (all code, no visual editor).
I haven't touched it in years but I remember moving to WPF because it had a better answer for binding UI elements to data. But while WPF does have an answer, everything is so fucking verbose and clunky.
>This barely mentions Windows Forms
Apparently, you do too, since what you said is basically the same as what the article said (.NET wrapper for C#, fastest prototyping to date)
I went from win32/C++ to Windows Forms and I got a huge increase in productivity and quality.
It wasn’t all roses though, the high dpi support was atrocious.
Winforms is a Win32 API wrapper, so on the same level as MFC, not a separate UI framework.
It is a wrapper, but it's not quite on the same level as MFC. MFC really is a thin wrapper, almost 1:1 in most places. WinForms is more like VCL or VB6 in that it uses Win32 where it can but doesn't design around it, so in practice it's more high-level.
I always felt the problem with WinForms was the name. For many, many years I assumed it could only do forms (ie for data entry).
> From their perspective, gambling on a new managed-code framework had produced the most embarrassing failure in the company’s history
Most embarrassing failure in the company’s history that far.
I stuck with WinForms and complemented it with DevExpress since their first release and never looked back.
I still think WinForms is one of their best UI framework. As for WPF, intentionally avoided it since day one. I’m not fiddling with no XAML.
I would bet in Avalonia UI. It's like WPF but cross-platform. https://avaloniaui.net/
SDRPlay is using Avalonia for its SDRConnect desktop UI. That's the one native application based on Avalonia I've spent significant time in.
It's ok. I give it pretty high marks. There is a good deal of "lowest common denominator" in it, naturally due to cross platform abstraction. But, it's generally nice, and commercial licenses are affordable.
An honest accounting of this history has to call out Sinofsky's role, and it's not pretty. He nearly killed the company in pursuit of power, insisting that everything be brought under his control. Who pushed in 2005 that online and search had to be organized under Windows? That was Sinofsky. He forced the engineering team that most needed to move fast onto three‑year product cycles--sheer insanity, and just one of a 1000 bad calls that ultimately contributed to his ouster from Microsoft. And when it came time to plan his own exit from Microsoft, who did Sinofsky turn to? Jeffrey Epstein, of course, because that's what normal people do. Treat everything Sinofsky writes as an attempt to launder his reputation--then add another layer of skepticism on top of that--because Steven Sinofsky does not live in the same moral universe as the people whose careers and products he derailed.
As an outsider, it always felt that 'internal team politics' were the root cause of Microsoft's technological downfall. This went far beyond the GUI. In 'flagship' offerings like SharePoint or Skype/Lync/Teams you could see the unmixable partial code-bases brutally forced together under a single product name an foisted upon a user-base baffled by how this could have gone so wrong.
A single product name, you say? COPILOT, COPILOT, COPILOT!
At Redmond, there was also the Patterns & Practices group (P&P) that tried to make sense of the dev products, and built extra libraries “to show customers how to use them”. They followed the bouncing ball of the frameworks releases from the main development teams. It suggests that it wasn’t clear exactly how you’d use the main products: so P&P said, ‘try it like this.’ I also think the article didn’t say much about MS in the web era. The company survived webdev IMO, but it definitely wasn’t the leader
Microsoft GUI development is a mess. They don't seem to care. Just look at the mishmash of different GUI styles in Windows 11.
Thankfully I have been mostly insulated from it by sticking to Qt and C++ for the last 25 years.
Qt/Win is enough to get the job done. Not always pretty, but it works. I used to be somewhat ashamed I never learned the actual Win32 API to write native apps, but now it looks like that was time saved. This is a great article.
A couple of years ago I played a bit with Go and Win32.
I got to the point that I could create windows and controls, and had a basic message loop working.
I then started dabbling in painting in non-client areas. It was buggy and didn't work well (my fault), but then I could see 2-3 different Windows UI styles competing to draw the window chrome.
The amount of crumbs hidden under the Windows carpet is incredible.
Windows frameworks got web envy.
Xaml and styling and all sorts to try and compete.
Trouble is, it made desktop development harder, and it didn't win against the web. It left the simple and safe formula of standard and common controls for a designer's playground, but the designers preferred the web. And if you make something for the web, you can package it in Electron and get cross platform cheaply.
Microsoft's biggest mistake was .Net being a Java competitor when it should have just been like golang producing native binaries. Especially since .Net was realistically only going to succeed on x86/64 at that point (late 90s and 2000s). This shut the door on C# for consumer UIs, and people stuck to Visual Basic and MFC.
It took them more than 2 decades to finally support pure native binaries (via NativeAOT). And it's fantastic for servers on Linux.
The problem was in the early 2000s it was basically accepted x86 was a dead end whose days were numbered.
Itanium was the heir apparent but importantly basically vaporware. How do you develop software NOW and more importantly sell and ship software NOW that'll work on a CPU you don't have access to and for which good compilers don't really exist yet? I remind you in the days where online updates were a luxury at best.
Processor agnostic CIL/JIT code was the prescribed solution at the time. Java had lit the way, and it was the only "clear" path forward for better or worse.
Little did we know Itanium would implode, and x86-64 would rise and give 20+ more years of binary compatibility.
They were recovering from all of the security fiascos of software that wasn’t being updated. So they pushed as much as they could into the core libraries and forced only one version to be installed at a time- so they could easily push security fixes.
This led to one of the trickiest things for early .NET consumer apps- getting the latest runtime installed.
This article smells so strongly of AI that I'd be surprised if the author did much of any writing.
I found the article itself very informative and not particularly ai-tastic. But then I got to that infographic at the end. Holy smokes was that disappointing. It seems clear they didn't even bother to read the captions the AI scribbled.
The summary of various frameworks and languages available is very concise and informative though.
It starts out alright, and then ends with a pile of classic Claude-isms and an unreadable slop graphic. Like the author got bored of writing it halfway through.
"Unreadable slop graphic" xD
So the windows team hates .NET, so they use react webviews and put them in explorer and start menu???
You have managed to concisely summarize the progress of Windows UI development for the past 15 years, yes.
They use react native
I very much dislike WPF. If I have to do a windows UI (and usually when I do it's a simulator for some piece of hardware), I honestly just grab WinForms. It's stupid simple.
Same here. Also the benefit of a visual Editor in Visual Studio is just Premium. Windows.forms also allow all those „modern“. Takes on ui either with ownerdraw or some grids/hand layouting.
To quote Steve Jobs: "The only problem with Microsoft is they just have no taste. They have absolutely no taste. And I don't mean that in a small way, I mean that in a big way, in the sense that they don't think of original ideas, and they don't bring much culture into their products. "
Winforms is still compelling to me. Now that we have WebView2, building complex hybrid apps is trivial. I know I could easily go pure web, but something about having proper native chrome feels better as a user. All of my clients/users are on windows so I stopped fighting this battle years ago. I've recently been using .NET10 + Winforms + WebView2 to build custom ai assistants for others. I cannot imagine how much it would suck to iterate the presentation of a conversation history in pure win forms. The hybrid stuff is crazy productive.
Given how bad windows has become since windows 7, I’ve been wondering. Does Bill Gates still use Windows? Does he put up with the horribleness?
The guy getting std’s from Russian girls who Warren Buffet doesn’t talk to anymore.
That Bill Gates?
Seems he might have other priorities these days?
I think Bill pretty much chilled out since he stepped down?
I just looked into this a bit because I thought he still had some kind of role at Microsoft even after leaving as CEO/chairman, but it turns out that in 2020 he left any and all positions at Microsoft as it was investigating him over inappropriate sexual relationships he had with Microsoft employees.
Before that he had a role as a technical advisor and sat on the board of directors.
I also found it interesting that Steve Ballmer owns considerably more of Microsoft than Bill Gates (4% for Steve Ballmer while Bill Gates owns less than 1%).
1 reply →
Yeah of course. He has nothing to do with Microsoft operations or strategy. But does he still use the products?
2 replies →
He’s still around as a part time advisor, he has to officially step back or no one would take Satya seriously, but on important stuff like AI he is a bit more active.
He's mostly been hanging with Epstein and asking for people to buy him STD medication due to his endless trysts
No im sure he uses linux or osx. Everyone uses this since windows phone was killed
If he doesn't use Windows, you won't hear about it. And if you hear that he uses Windows, it might not be true. He loses nothing by denying it. If it worked for his friendship with Epstein, it will work here.
Today i still use C# with Windows.Forms. All my old knowledge is still usefull. People know how to use a Windows.Forms program.
It’s great, some vendors have fantastic component libraries for reasonable prices.
Unreal that MS bet the farm in Windows on so many other turds instead of boring old WinForms/Win32.
This is what happens when one's performance is measured by "impact".
> I sat through a conference session in the late nineties trying to understand the difference between an OLE document, a COM object, and an ActiveX control.
I wonder if we attended the same conference session!
A decade or so ago, I had a clear idea of what a "native ui" should look and feel like, even if there were multiple routes to get there. I don't know any more.
The roadmaps look messy if you look at them as coming from one company. But if you remember that windows and .net (or DevDiv) are more like competing companies then it makes more sense. Then for one side it’s Win32, MFC, WinSDk and for the other it’s Win32 (WinForms), WPF, MAUI
If Microsoft hadn’t been preoccupied with a failed mobile bet then this wouldn’t have happened. It’s a lost decade followed by a (much more successful) cloud pivot. The reason desktop is ignored is because it can be. No one is eating their lunch on desktop.
The writing style was really poor. Too many words saying too few things.
Entirely AI. I just can't with this style anymore.
Programming Windows is THE authoritative source on Win32 programming: https://www.charlespetzold.com/books.html
It is a fantastic book, I learned everything I know on Win32 from it. Wrote real time scientific software in windows for ~10y! We did it all, external hardware control, custom UIs, etc. Thanks Ryan Geiss for your timing info.
Right about VC6 was the sweet spot imo, C/C++ with lightning fast UI for docs and more. Tools got out of the way. Once other languages got involved (C#?) the docs got out of control and harder to use, and the UI started to get a little overloaded.
The snappiness of those old windows systems was pretty great.
For some reason I associate this with this article
https://blog.hiler.eu/win32-the-only-stable-abi/
The root of the problems seems to be trying to find a holy grail design that works across all their businesses. Surface tablet mode, touchscreen laptop, touchscreen desktop (surface studio), mouse and keyboard PC, stylus input, etc.
Then there's a lot of legacy stuff that needs to continue working because otherwise you end up with a non backwards compatible windows.
Then you have to get everyone at microsoft across all their bajillion products to change the UI from Task manager to the 5th level of settings for some obscure ODBC connector.
It's not going to happen I suspect
Microsoft has a very coherent strategy, described aptly in "fire and motion" by Joel spolsky 24 years ago: keep changing the API/GUI every 2 years:
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
Both this blog post and the Steven Sinofsky response really set my blood boiling, because they both reek of retired-executive score settling, a kind of blame game that gets played out decades after the fact between ex-high-ranking people in hopes that whoever writes last is able to cement the conventional wisdom.
People who play this corrosive game either refuse to believe that they are at fault for not changing what they were doing at that time or speaking up about what they were observing then, or they know they're at fault and want to deceptively distract us from that fact. Either way, ask yourself this: "Aren't they sorry?" If they're not, just move on.
The most offensive part of the Sinofsky response is this part:
> WinRT (2012) - it (or the embodiment in Windows 8) failed in the market but it also showed both the problem and potential solution to building for new markets while respecting the past
I can't express how wrong this is. WinRT was the most destructive thing that the Windows team ever did to the OS. It drove a hard stake into Windows, splitting it in half and declaring that anything previous to Windows 8, oriented toward desktop, or using primary input through mouse and keyboard over touch was dead. Microsoft basically told all existing Windows developers that if they weren't building a new, touch-oriented, mobile-style app specifically for Windows 8, they didn't matter and wouldn't get any support whatsoever, which is exactly what happened every time they broke existing desktop functionality. Calling this "respecting the past" is a crass insult and taking no responsibility for damaging the Windows development experience and accelerating development away from native Windows apps.
I think for Sinofsky the "respecting the past" refers more to WinRT was/is still just Spicy COM under the hood. Most of the article as I read it is about how .NET was a mistake for Windows UI development and a return to (Spicy) COM its savior.
4 replies →
“Retired general criticises the Pentagon” is practically a trope.
That illustration at the end of the article is quite something.
What are you talking about? As a "Chrondum and frade.js" developer, I found it very flelpful.
I for one am on the Mindows Seam, where I can enjoy the books of Charloy Reccold.
Quite some slop
Has it become unreasonable to use an image editor for anything? At least to stamp some readable text on top of your slop??
Sometimes I really don't know whether to laugh or cry.
I used the more recent Petzold examples to successfully bind DirectWrite to Direct3D, but yeah it’s been a crapshoot otherwise. Still have the Windows Programming (5e?) bible around here somewhere. Took awhile to grind through it. I dread modern-day windows programming it seems like every OS release some new API is going to overtake the others. I moved on.
I blame "Impact". That's what you are graded on at Microsoft. Every performance review ('Connect'), every stock award, every promotion run: did this person have that magical impact.
Ostensibly, grading by impact is fine: they want people who make a positive difference. In reality, it means that creating is better than finishing. Now add in the cold realities that at any given time in Microsoft, some groups are on the up and some on the down. What's a great way for a group to regain some status? Launch something. Jazz it up for the Build or Ignite crowd. Get some dev evangelist to talk about it. Then get on the job board and slide over to another team ASAP. You're a High Impact person. Who wouldn't be happy to have you?
If my assigned tasks are A,B,C and I do all three 100% correctly, on time, etc, it makes zero difference on my impact.
I need to ignore those and do D,E,F instead to get promoted.
Petzold is a legendary programmer. His book Code is worth reading: https://en.wikipedia.org/wiki/Code:_The_Hidden_Language_of_C...
Not just Windows. If you use an Android smart phone (and it might be just as bad on iPhone I just don't know) you see AI features occupying the last scraps of user interface real estate in the form of edge gestures that half the time get me an unwanted AI overlay UI when I was looking for the app switcher. Steve Jobs is spinning in his grave, and the people who authored the original Mac UI guidelines are cringing. Nobody seems to be willing to say that there's no room at the inn, or that somebody's idea has to get evicted before a new idea can occupy space.
Microsoft itself is a business driven by a consistent strategy of striving for market dominance no matter the means. looking for coherence in the resulting DX is missing the forest for the tree.
This 2018 video from TechAltar discusses the same topic: Why Microsoft Can't Design A Consistent Windows (https://youtu.be/hn5QjtpjW_U)
MS Windows is walking joke for at least a decade, UI consistency isn't it biggest problem. Unfortunately both Linux and MacOS have their own deeply seated issues. This leaves users in an unenviable situation and encourages experimenting, with AI encouraging more and faster attempts. When AI are getting better... I hope this question will become unimportant sooner rather than later.
Worth mentioning a discussion on a similar blog post two weeks ago;
Windows Native App Development Is a Mess
https://news.ycombinator.com/item?id=47475938
Reading this was such a trip. I remember "Programming Windows" had to bribe my uncle to buy it for me. I built my first app using it.
I would recommend Flutter, if Google would not have abandoned it. 12000 open issues on GitHub speak for themselves.
One could argue the 17 solution summary is actually correct? Why should an os be limited to just one way of doing things. I don’t believe my own words 100% but it is a thought that maybe diversity is the eventual outcome. Ubuntu and MacOS are kinda fighting the same battle. Is that just the way it is?
It's bad enough that Microsoft doesn't have a satisfying answer to this question, but what makes it worse is that WinUI feels weirdly non-native in ways that sort of uncomfortably result in Electron apps feeling more like real Windows applications.
It's worth noting though that Apple is on a similar trajectory and is now in a very nearly as bad position given all the serious issues with SwiftUI and how badly it has fragmented/degraded Mac desktop application development.
It's almost like the major desktop platform vendors have all given up on supporting high-quality native desktop applications.
> It's worth noting though that Apple is on a similar trajectory and is now in a very nearly as bad position given all the serious issues with SwiftUI and how badly it has fragmented/degraded Mac desktop application development.
Apple (and Next before it) have been iterating on Appkit/UIKit for three and a half decades.
Now they have added SwiftUI as a second option and have been iterating on it for a bit over half a decade.
This is in no way similar to Microsoft creating and abandoning another UI framework every couple of years.
If Microsoft had been steadily improving Win32 all these years, where would it be today?
The web revolution is to Windows UI what vibe coding is to programming today. It brought in a massive group of people who didn't need to understand message pumps, or handles or non-blocking api calls. On top of that, it delivered incrementally more capable result each year. View source taught millions how to build modals, blurred overlay. Meanwhile, the old group of programmers were still worrying about how to protect the knowhow behind compiled languages.
I agree with the thesis of your post, but where we differ is that I think both of those were (are) bad things. Both web apps and vibe coding are causing the market to be flooded with low quality software, not only making the market worse but also giving future generations fewer examples of well-made software to look up to.
Case in point after Edge updated this morning:
https://imgur.com/a/dWp5Ohj
Did they even try to make it look like the new context menus?
Well, Edge is Chromium. They need to maintain a hard fork, not just a reskin with a bunch of Microsoft webpages and adware. Chromium basically allocates a window and completely draws everything inside using DirectX APIs including menus.
I was recently exploring "an OS from scratch" architecture with ChatGPT. Apart from the central idea that I wanted it to be a capability OS, I also started thinking about how I'd make GUI apps and what layers would naturally make sense.
The cleanest design I came up with works like this:
1. At Layer_1 OS provides panes or windows to which apps can render whatever graphics using OS gpu lib (think Raylib, but maybe a bit simpler). This is good for apps that want performance, games, text editors, things like that - so this is maximum control.
2. Next Layer_2 would be based on the browser engine (which, to some degree, would have to be developer - not a full browser, but just enough to render more or less modern html/css with a DOM-aware JS engine). Then provide some XML schema that would automatically translate into HTML/CSS to render various UI-widgets (defined by XML/HTML elements). This would eventually suggest a JavaScript UI framework on top, but no a requirement. This layer is flexible enough that it uses widgets defined by the system, but allows custom CSS and JavaScript.
3. Layer_3, or more like Layer_2.5 would basically allow custom HTML/CSS without relying on system widgets and XML schema.
Obviously you can mix all three layers into one GUI too. Finally layers (2) and (3) would require some client/server architecture, but instead of shipping it like a webapp, I'd probably provide some JavaScript API to talk to the backend (which in this case is accessible via a socket of some sorts). Apps themselves could still be single binaries that include html/css/js assets which are provided at launch time to the system UI renderer, which then uses them to render the UI via a webview in said pane or window.
I think it's pretty slick and it only gets complicated gradually, but it also requires solid OS plumbing and machinery to make this process smooth. None of the modern systems are capable of it in the way I described it, so people end up shipping nodejs/react apps with webview inside gigabyte-binaries.
L1: Wayland, L2: QML / Slint / XAML etc, L3: Yes, these allow custom widgets
Petzold literally had the Windows logo tattooed on his arm. He was a true believer.
Has anyone tried turning Microsoft off and on again?
Talk about UI without pictures!
While reading all these comments I keep asking myself if these are the same people who would get angry at another Election app because someone was lazy and didn’t make it native.
I had the displeasure to work with various MS systems over the years and coherence is not a concept in Redmond. It just isn't.
The layers of outdated and conflicting documentation, fragmented logins, the naming (365, live, .net [both naming everything that and the .net core naming labyrinth], copilot), Teams never made sense, Windows had levels and levels of settings (win10 preferences all the way back to dialogs predating the mammoth).
MS was, is and always be a blight upon this earth.
I think that is an insult to MS Bob
Good tech solutions need ONE champion.
Jobs, Musk, Edison, whoever.
Someone who will enforce their design decisions, get stuff done. And take the hit when they are wrong.
The UI strategy of the future may very well be HTML. It's widespread, standardized, sufficiently performant, and pretty rich.
What'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.
not exactly the same, but worth noting that in a spectacular display of being too early, microsoft shipped this 30 years ago (active desktop in 1997 merged the windows explorer with internet explorer, turning folders into web pages).
It is despised for the same reason web based UI is despised today. Firefox OS was also “too early” and failed.
1 reply →
I've been hearing that for 10+ years. This is not going to happen.
This has already happened de-facto. Optimize it properly, and the whole problem disappears.
HTML and CSS are also absurdly hard to actually do anything useful with or interactive compared to normal desktop or app frameworks.
Orders of magnitude more BS, plumbing, awkwardness, head scratching, etc.
That was indeed a pain point, but not anymore after CSS flex layout became available some 10 years ago. It's not worse than WPF for sure. It's even better than WPF because you have access to tons of UI components and toolkits that work everywhere.
3 replies →
That’s the strategy of 20 years ago.
There's a competing webapp-wrapper framework that explicitly uses the platform's own browser, but developers don't like being at the mercy of whatever the OS ships...
> sufficiently performant
In no universe is HTML performant compared to actual desktop applications. It sucks big time.
The tl;dr is basically to stay with Win32 and ignore all the new and shiny.
That AI image at the end was more amusing than informative. Almost lost it at "Win15" and "Chrondum + frade.js".
I feel this so hard.
It's all win32 underneath except for UWP, which is now deprecated.
so the answer is win32, raw winproc.
The issue is they haven't made a new GUI API (only frameworks) since win32.
To add the UWP APIs were always less than the win32 ones in the name of security.
The issue was they didn't give you an alternative they just said don't do that.
so inevitably at some point you decide to just write it in win32, don't ship in the store, etc so you can get things done.
If an app has a zip download or a Microsoft Store link, the zip download is always a superior experience. UWP is a huge fail
> WPF shipped in late 2006. It was remarkable – XAML, hardware-accelerated rendering, real data binding. If Microsoft had made it the definitive answer and invested relentlessly, the story might have ended differently.
Er… The author perhaps never used it? WPF was the worst framework I ever used. It was unbearably verbose, brutally unforgiving, used 2-way bindings that created updating nightmares, ans not the least it was incredibly slow.
WinForms was not the best for sure, but at least you can get stuff done. It was for a long time the right answer to the question the author asked. .Net + WinForms worked well.
When WPF shipped was when the shit hit the fan.
All that and they abandoned it at birth. It never felt finished and got little to no attention for years.
> XAML
This is the common thread of all their frameworks since, and in my mind the reason they are stuck in an absolute quagmire. For a while it was possible to use HTML/JS in UWP (I think), but it didn't stick due to everyone already needing to move over their LOB apps with crazy amounts of XAML so that's what the focus was on.
"Hey, let's make something that's vaguely HTML but not really at all."
Big mistake.
Avalonia and Uno are repeating that mistake, even though with Uno, at least, there's a blessed way to do unidirectional data flow/reactive stuff.
Two-way data binding is the devil.
The funny thing is that Joel Spolsky predicted most of it 20 years ago[0]:
>> Jon Udell found a slide from Microsoft labelled “How Do I Pick Between Windows Forms and Avalon?” and asks, “Why do I have to pick between Windows Forms and Avalon?” A good question, and one to which he finds no great answer.
And:
>> Which means, suddenly, Microsoft’s API doesn’t matter so much. Web applications don’t require Windows.
What he didn't see is, however, Azure would become the money printer for Microsoft and made all these no longer matter.
[0]: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
Why tie your app to Windows at all?
Microsoft developed VS Code and Teams in Electron. That says a lot about how they see the future.
I stuck with WinForms. It was the last tech that made your app look and feel like Windows app.
Everything that came later was basically a struggle to make something that Electron actually delivered.
IDK, it kind of sounds like from the article's own prose that Project Reunion / WinUI 3 is an overall good thing and that Microsoft actually does have a pretty good vision for the past 5 years at least.
From a user's perspective, I don't really see where the problem is. All my apps look like Windows apps to me, and I also think that includes apps that do their own thing and look their own way. For as long as Windows has been around we've had apps that just don't follow the rules, from RealPlayer to WinZip to iTunes to Spotify.
This idea that all applications must be consistent with each other on one platform is generally a good idea but the downside of not having it that way is not very tangible to most users.
E.g., Steam looks different than every other Windows app. Same with Spotify and Slack and Discord. How does that negatively impact users? Well, not really at all. The consistency is within those apps themselves. I'm comfortable with Steam because I've been using it for 20 years and it's evolved on its own terms.
I could see it being an accessibility problem, but can't figure out any other potential downside.
I also don't think any other platforms have this figured out. See the window corners in macOS Tahoe. Remember how Mac Catalyst apps first looked when that came out? They didn't follow OS conventions at all. Remember when Final Cut Pro 6 didn't look anything like a Mac app? Or GarageBand etc. and their skeuomorphic looks? Linux is no better with a mix of desktop environments, Wayland versus Xorg, etc. Then we look at mobile apps and it's one of the least consistent environments imaginable: you've got a mix of native and frameworks like React Native and Flutter and the rest.
They have a strategy of adding as many dumb slow abstractions as possible so the multi trillion dollar company can minimize the devs on their payroll.
This will never change. All large orgs are this way because at the end of the day, unless its preventing them from making profits, there is no incentive to change it.
Moreover, there isn’t much in the way of alternatives. Everyone likes to hate on MS —for decades this has happened and nothing came of it.
WPF marked the end of well thought-out UI’s and standards. It’s been web-inspired slop ever since.
Anyone else sit through one of those Microsoft "Project Reunion" and wonder "what the hell is even this?" Microsoft has had a completely confusing UI strategy for years.
"I looked at the presenter like they had a rat’s tail hanging out of his mouth for the entire hour."
Could have been Ballmer getting a quick snack in before anger-presentation.
Couldn’t someone do a similar story about scripting on windows, and make Jeffrey Snover one of the punchlines?
Starting with Metro every Windows UI framework has been beyond ugly. there's just something so backwards over how nice the UI was in Windows 7, I simply can't understand it.
Metro was created partly to run smooothly on cheap Atom tablets and Windows Phones. Then Microsoft shifted their focus elsewhere and iOS 7/OS X Yosemite happened so they have all the reasons to stay flat.
Updated apps look fine, but the majority aren't. And with that bizarre "Show More Options" nesting in the Windows 11 context menu it almost seemed like Microsoft is no longer capable of upgrading old components in place.
At this point I don't get why they don't open source Windows and developer tools, make a foundation to steer the code, accept contributions and borrow ideas from other operating systems.
One of their problems is borrowing ideas from other operating systems. Windows is full of Apple envy whether the addition made sense or not.
Honorable Mention: Lazarus
Nobody 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.
KDE has the newer QML-based Kirigami and older Qt Widgets frameworks that are not consistent. Widgets apps absolutely look like actual desktop apps (menus, toolbars, dialogs), Kirigami apps look like mobile apps (nav bars, hamburger menus, page-based navigation). There is definitely a visual and functional inconsistency between the two, even if they use the same theme pretty well.
The problem with things from the Linux world is that they never reached the height of commercial desktops to begin with.
If you really enjoy worse Windows XP UX with hamburger menus in recent versions then by all means go ahead, it does function.
Every year the same debate, every year the same Microslop apologists in the comments, every year nothing ever changes, every year Microslop's market cap keeps groing, every year the same problems
Microslop should have been dismantled decades ago, it's now too late, we need a paradigm shift so that Microsoft no longer affects our society
Every year Windows loses a little more market share.
funny thing is, with AI, it's become really easy to put win32 apps together, and they load fast and are super responsive!
I'm not sure I can take such an article seriously if it doesn't mention that the WinRT/UWP/WinUI stack is also based on XAML, and that a fundamental design goal of WinRT was to let people use either C++ or C# according to taste.
Also, the AI smell in this article is just too much.
Here's how I think Microsoft can get a quick and sustained longterm win in GUI (/s but only partially) -
1. Drop all its GUI stacks apart from legacy Win32
2. Port KDE Plasma to Windows (with aliased bindings to support traditional explorer.exe calls so as to not break user apps)
That's it. There really aren't many significant apps that use the rest of Microsoft's stack apart from Win32 that won't recover from this, and Microsoft itself will just see a massive drop in its own costs with a massive rise in user satisfaction.
The slop image at the end made not read anything in this article.
s/\sGUI\s/\s/g
OLE objects are just like disk images.
It’s web. Just use electron or Tauri.
Oh hey look, another chance for HN to dunk on Microsoft. I’m sure there will be some fresh new perspecti…oh darn, it’s just a rehash of the exact same snark the last time HN had a chance to dunk on Microsoft.
I’m not sure what Microsoft can possibly do when the closest thing to a collection of power users is this painfully repetitive.
> Dead silence. One person suggested WPF. Another said WinUI 3. A third asked if they should just use Electron. The meeting went sideways and we never did answer the question.
> That silence is the story.
These LLMs are just awful at writing.
I felt fatigued after the second paragraph. All these LLM tropes chained together are horrible to read.
I was weathering the excessive and confusing analogies and then I read:
>introduced a level of cognitive complexity that makes Kierkegaard read like Hemingway.
and I fucking lost it.
Yes they really do a great job at mimicking awful human writing of that horrendous style, whatever it's called. Post-TED NPR style bougie blogging let's say.
This site needs a no LLM submissions policy too.
I flagged the post, don't even care how accurate it is. Go send your AI slop to /dev/null, folks.
that part really didn’t make sense to me. This is true for all desktop platforms.
I agree, although I was talking about:
WHAT SILENCE?
2 replies →
[dead]
[dead]
This is a problem with all the OSes.
I disagree. KDE and Gnome both have pretty consistent UI strategies. You may or may not like them but they have clear identities and design guidelines and follow them.
GTK1, GTK2, GTK3, GTK4, GTK5. Qt1, Qt2, Qt3, Qt4, Qt5.
WPF was atrocious from the beginning and Microsoft absolutely did the right thing by not basing everything in Windows on it.
Every WPF program was laggy and took ages to even start up (is everyone forgetting hard disk speeds?), partly due to it being managed code. The components didn't feel native either, and the coupling to managed code and garbage collection basically ensured all those would be perpetual issues. Yeah the programming model was beautiful and all, but you're supposedly developing to make your customers happy, not to make yourself or computer scientists happy.
You can see how terrible it would've been to base Windows's shell on WPF by looking at how much users have loved the non-Win32 windows since then.
I’m not sure I would blame the problems of WPF on managed code. After all we had snappy WinForms applications before WPF came along.
Kind of yes, kind of no:
- WinForms applications also took visibly longer to load than Win32. I didn't dread loading them nearly as much as WPF, yes, but I still did. They weren't what I'd call "snappy", but they were... usable enough.
- WinForms also stuttered (in my experience) with the GC. Again, not "snappy" in my experience, but this was more dependent on your use case.
- WinForms were .NET 2.0 rather than .NET 3.0, with fewer modules to load. It certainly felt more lightweight, which from my memory (of how the hard disk behaved) correlated with that.
I'm planing on switching over to QubesOS - way more secure (especially considering rogue LLM-agents) and visually not much worse from windows ... maybe even more cohesive.