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.
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...
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.
I am going to add my favorite here, just to rant into the void. A dialog box's options must never be Ok/Cancel. These are not the same sorts of things. "Cancel" is a verb, "Ok" is a noun (in this context). Even if "Ok" is taken to mean the verb "acknowledge", it is still not an alternative to cancelling.
99% of these dialogs should be "[Verb]/Cancel": Change "Ok" to a verb or short phrase indicating the action that will be taken if you press it. Don't do the action if the user hits "cancel". The verb should be something specific like "Delete file" or "Terminate process" and not something useless like "proceed".
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.
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).
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 ..
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).
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, 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.
The web is not consistent itself. Lots of sites, and most web apps, invent their own UI.
Hopefully /s
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...
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.
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 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...
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.
[1] - https://arstechnica.com/gadgets/2008/03/the-vista-capable-de...
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...
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).
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.
Displaying text is surprisingly hard, as one can easily find out if ones dives into the big rabbit hole of font rendering.
But they just plain failed to execute well on this idea.
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.
You can just render on a canvas like flutter and KMP. Most end users don't care
Apple solved this by treating the design system as the product and letting the framework be invisible. Microsoft has it backwards every time.
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.
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.
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..
What a laugh, do you want the examples on Apple's side?
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.
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.
This comment written before Tahoe
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.
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.
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.
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.
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.
There aren't really that many apps that make sense to work in a full-fat form all the way from wearable to phone to tablet/laptop/desktop.
Tablet/Laptop/Desktop is probably solvable by a single toolkit set (remember the brief era of Windows 7/8 tablets, many of which had fold-back or snap-on keyboards and pointing devices if you needed precision beyond what a touchscreen could offer?) but I don't really want to run KiCAD on my phone or a smartwatch, for example.
Saying outright "we have different tooling for big and small devices" (or even three sets-- large device/handheld/wearable) should steer developers into providing tools built to the task and purpose. Maybe the phone/wearable version only has limited tools that work well on a tiny screen and is as a result smaller and more efficient?
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.
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.
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
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.
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?
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.
Why write an anything-specific app?
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!
[1]: https://learn.microsoft.com/en-us/previous-versions/ms536495...
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 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.
Nonsense. The best experience is the one that solves user’s issue. Technology choice is orthogonal to that.
They had something reasonably good in WinRT. They should have stuck to that. But Nadella came in, said Azure Cloud is the future and abandoned the Windows platform.
Microsoft 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 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.
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.
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?
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.
Painful and nonsensical from a desktop standpoint but also kind of impressive in a way.
I would not be surprised if you still cannot launch a fricking .exe.
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).
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.
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!!!"
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.
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.
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.
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.
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).
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.
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.
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]
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.
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.
Fortunately Rails was taking off at that point so it was fairly easy to change horses and just ignore 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.
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...
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.
.
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.
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.
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.
Java. Java is the problem .NET attempted to solve.
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.
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.
(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.
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.
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.
I am a desktop app "believer" I like desktop apps, I like native desktop apps, but I also have to make software that makes economic sense, and following Apple's guidelines just doesn't make any sense for me, and a lot of other companies too.
- 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.
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.
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:
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.
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
A few years ago, I wanted to prototype something quick and I wrote it in Windows Forms over C# (all code, no visual editor).
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)
It wasn’t all roses though, the high dpi support was atrocious.
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.
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...
Most embarrassing failure in the company’s history that far.
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.
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.
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.
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.
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.
Thankfully I have been mostly insulated from it by sticking to Qt and C++ for the last 25 years.
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 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.
Any trade-off that favors the enterprise in lieu of the user actually benefits nobody in the long term.
That Bill Gates?
Seems he might have other priorities these days?
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%).
Microsoft has been developer first, then cloud first, now AI first. It has never been design first. And when something does work, the pattern is always the same: force it everywhere. Metro was genuinely good on mobile, then they pushed it onto desktop where it didn't fit. Now Fluent UI is repeating the cycle.
Fluent UI is on its third major rewrite (Fabric, then Fluent UI React v8, then v9). Each one brought breaking changes. v9 appeared around the same time Microsoft released their new Teams client, and it shipped with performance and accessibility issues that are still being worked through. Signs already point to the next throwaway Fluent UI version. In practice, Fluent seems to be first-party only. It's 'open source' in the sense that you can look but don't touch. In SharePoint alone, the same UI elements look different across pages, lists, document libraries, and settings panels.
The irony is that the web platform itself has caught up. You can build a fully themed, accessible component library in plain HTML and CSS today. No framework dependency, no version lock-in. I did exactly that with hTWOo (https://htwoo.io/), an open-source alternative that matches the Fluent design language without any of the React coupling.
The real problem isn't that Microsoft can't pick a GUI strategy. It's that they keep rebuilding from scratch instead of creating a design system flexible enough to sustain across platforms and product generations. The web platform already provides the primitives. You just have to commit to them.
Unreal that MS bet the farm in Windows on so many other turds instead of boring old WinForms/Win32.
It took them more than 2 decades to finally support pure native binaries (via NativeAOT). And it's fantastic for servers on Linux.
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.
This led to one of the trickiest things for early .NET consumer apps- getting the latest runtime installed.
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.
Has it become unreasonable to use an image editor for anything? At least to stamp some readable text on top of your slop??
He's claiming Microsoft pitched "WitdFT" (sic), "HTMLAl5" (sic), and "C++" sonuitaneously (sic) at Build 2012.
HTML5 was released in 2008 and the C++ reference was released in 1985. How is this acceptable?
Windows Native App Development Is a Mess
Microsoft developed VS Code and Teams in Electron. That says a lot about how they see the future.
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.
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.
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.
> 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.
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?
I need to ignore those and do D,E,F instead to get promoted.
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.
If you really enjoy worse Windows XP UX with hamburger menus in recent versions then by all means go ahead, it does function.
I could use Konqueror, I guess, but its ad blocking plugin (and plugins overall) seems to never have progressed much since KDE 2.
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
Did they even try to make it look like the new context menus?
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.
Everything that came later was basically a struggle to make something that Electron actually delivered.
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.
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.
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?
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.
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
That AI image at the end was more amusing than informative. Almost lost it at "Win15" and "Chrondum + frade.js".
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.
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.
I wonder if we attended the same conference session!
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.
Orders of magnitude more BS, plumbing, awkwardness, head scratching, etc.
In no universe is HTML performant compared to actual desktop applications. It sucks big time.
Could have been Ballmer getting a quick snack in before anger-presentation.
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.
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.
Jobs, Musk, Edison, whoever.
Someone who will enforce their design decisions, get stuff done. And take the hit when they are wrong.
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.
To be brutally honest, if you were a serious Windows developer in those days (and you were even the sort who'd have sat through a conference session on the topic); there is absolutely no way in hell you'd not understand the difference between OLE, COM, and ActiveX. Conflating these things as some sort of confusing mess either shows a lack of actual experience, a lack of competency, or a desire to falsely make things seem more confusing than they were to add some meat to an article.
This article dances with some good points, but opening up with this sort of hyperbole (and then ending it with an unabashed AI slop image filled with brand new hallucinated characters of the alphabet) just totally tanks the author's reputation.
Also, the AI smell in this article is just too much.
>> 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...
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.
I’m not sure what Microsoft can possibly do when the closest thing to a collection of power users is this painfully repetitive.
> That silence is the story.
These LLMs are just awful at writing.
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.
>introduced a level of cognitive complexity that makes Kierkegaard read like Hemingway.
and I fucking lost 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.