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.
It is absurd that there is no standardized UI toolkit, or rather that the web browser _is_ the standard with is characteristic _lack_ of user interaction idioms.
The fact that there are multiple platforms for UIs* is a huge failure of the industry as a whole. Apple, Microsoft and Google could have had a sit down together at any point in the last 20+ years to push some kind of standard, but they decided not to in order to protect their gardens.
*: a standardized UI platform doesn't necessarily mean a standardized platform. Just standardization of UI-related APIs and drawing.
My guess 10 or so years ago was that Google would be the first to bake Material UI into browser with web components, and then any browser would essentially reuse that to extend out whatever style they wanted. It really seemed like the way the web (and Google was heading). Instead we got bad Material UI knock-offs in about 45 different UI frameworks.
I'm not convinced that it's possible to create a UI toolkit that works on both desktop and mobile without one compromising the other. It's a bit like trying to design a vehicle that can serve both as a 2-ton pickup truck and as a golf cart; the needs of the two are just too different.
Another reason is that in 2000 if you wanted pointless UI wank you had to implement it yourself from scratch. Today with bloated frameworks where the developers ran out of ideas 15-20 years ago and have filled the intervening time adding wank that no-one asked for and no-one needs, everything you build with it gets to include every brain fart someone had at 4am back in 2017 that they thought looked cool at the time.
> basic rules that had been in place for ages. Things like: [...]
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".
IMO the ubiquitous Yes/No/Cancel is even worse. No and Cancel are too conceptually close. Doesn't help that these usually show up when you're about to lose all your unsaved changes.
We've got big screens now! use more words! Save changes/Discard changes/Don't quit.
I understand those prompts perfectly fine, but they are panic inducing for e.g. my mom who has about a 50% chance of clicking the wrong button and losing work.
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 ..
> 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.
No. I want things like keyboard shortcuts to reflect the platform norms of where the app is running (macOS in my case). A shared core is fine, but the UI framework must be native to be acceptable. Ghostty is a "gold standard" there.
This is why most web apps are lowest-common-denominator annoyances that I will not use.
Indeed, if the framework is sensible, keyboard shortcuts reflecting platform norms is entirely attainable in a manner that developers don't have to bother with it, much, if they don't want to.
There are plenty of examples of cross-platform UI's surviving the hotkey dance and attaining user satisfaction. There are of course poor examples too, but that's a reflection of care, not effort.
>i.e. dissuaded from using native, but rather bespoke, UI frameworks.
Based on my experience, I would be quite reluctant to rely on any non-native cross-platform desktop UI framework that is not web-based. These tend to be either less performant, look outdated or are bug-ridden.
Qt apps don't feel great on macOS, though it's by far the best for mac-ish UI. Dropbox was Qt for a long time and I'd argue it worked well for them. Its easy to fall into "uncanny valley".
On Linux, Qt apps feel a bit off in GNOME, though you can never satisfy everyone as its the wild west.
I think Qt also suffers from not really being anyone's favourite.
On the one hand, you have web developers who tend to not really appreciate the nuance of the desktop as a platform. They're not going to advocate for Qt, it's not CSS/HTML/JS.
On the other hand, you have native Mac developers who love Apple's toolkits (AppKit, maybe SwiftUI). They're not going to advocate for Qt either.
Lastly, you have native Windows developers who have been burned so many times they don't advocate for anything in life anymore.
QML is an entirely separate widget toolkit that really isn't a great fit for desktop programs - it's not much different from using a web-based toolkit.
QML doesn't have a way to define interfaces with JSX and doesn't integrate with the wider JS tooling. From my very limited experience, it still feels too close to the C++ world.
> This isn't true, but I understand why you feel that way.
By all means, I'd be happy to be proven wrong. Last effort I saw on this direction was node-gui + React. I believe that project isn't being maintained. Being able to use something like Vite to build desktop programs would be a blessing.
Widgets looks like whatever you want them to look like, if the feel like they're from the 2010s its because the implementer made that choice, not because of a limitation in qtwidgets.
As I understand the philosophy of Qt, it does not (for the most part) use native widgets. They seek to draw widgets that match native widgets on a pixel-by-pixel basis. You can also change the look-and-feel (similar to Java Swing widgets) by using what Qt calls "styles". Ref: https://doc.qt.io/qt-6/style-reference.html
Ah, the magic times when screen resolutions were large enough to display lots of information, in proper 4:3 aspect ratio, just before they got flattened and the industry started treating them as short view distance TVs.
That's your prerogative, but web-based UI's have their hard limits, and native cross-platform desktop UI's are no more/less problematic than the browser.
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%.
Sometimes this is a self-fulfilling prophecy. It is the novice users who, over time, become power users through repetitive usage. If there are no user efficiency gains to be had through experience in a UI, then it just prevents the emergence of power users. Users just have to wait until a product manager or designer somewhere notices their pain and create a new feature through 10x the effort it would have taken to simply maintain the lower level shortcuts (e.g. keyboard accelerators, simple step automations).
Was it the same 1% that was using each of the long-tail features? I suspect that by refusing to invest effort in at least some amount of niche features, we essentially alienate _everybody_
Browsers like Vivaldi that cater to power users are gaining in popularity. They are not trying to be the next Chrome, they are just out to serve their niche well.
Firefox has nothing to differentiate itself from Chrome at this point.
Not only that, but for a time, Firefox seemed to be copying everything Chrome did, maybe as a way to stop the exodus of users. But people who wanted Chrome-y things were already using it, and people who didn't might as well, because Firefox was becoming indistinguishable from it.
God I wish Mozilla would be made great again. It's tragic how mismanaged it is.
Is it mismanaged? Sure, they spend a fair amount on administration. Sure, they spend about 10% on Mozilla Foundation stuff. But they still spend ~2/3 of revenue on software development.
And they're somewhat stuck between a rock and a hard place.
If they try to evolve their current platform, power users bitch. If they don't evolve their current platform, they lose casual users to ad-promoted alternatives (Chrome and Edge).
And they don't really have the money to do a parallel ground-up rewrite.
The most interesting thing I could see on the horizon is building a user-owned browsing agent (in the AI sense), but then they'd get tarred and feathered for chasing AI.
Part of Mozilla's problem is that the browser is already pretty figured out. After tabs and speed and ad blocking, there weren't any killer features.
To a first degree, nearly everyone who installed Chrome did so because of Google putting "Runs best in Chrome" on every page they own and including it with every single possible download, including things like Java updates!
Almost nobody chose Chrome. Microsoft had to change how defaults were managed because Chrome kept stealing defaults without even a prompt.
People use "the internet", they don't give a fuck about browsers. Firefox only got as high a usage as it did because of an entire decade of no competition, as Internet Explorer 6 sat still and degraded.
Chrome was installed as malware for tens of millions of people. It used identical processes as similar malware. It's insane to me how far out of their way lots of "Tech" people go to rewrite that actual history. I guess it shouldn't be surprising since about a thousand people here probably helped make those installer bundling deals and wrote the default browser hijacking code.
It should be a crime what Google did with Chrome. They dropped Chrome onto unsuspecting users who never even noticed when malware did the exact same thing with a skinned Chromium a couple days later. Microsoft was taken to court for far less.
How was Mozilla supposed to compete with millions of free advertising Google gave itself and literal default hijacking?
Container tabs, independent proxy config (chrome only respects system-wide proxy), vertical tabs, and functional adblockers are the four big features for me.
Go to an adblock test page in Chrome and compare it to Firefox with uBlock Origin. Chrome can't block some ads, and some of the ads it can block leaves behind empty containers.
> 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).
> 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.
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.
Nonsense. Do you read and write your email using the command line? I use Mutt and Vim for that, and that’s not the command line. GUI with power-user support is just as efficient as Mutt and Vim. Did you use curl to read this thread and submit your comment? I use Firefox with Vimium C, which allows most web pages to be navigated and operated efficiently by keyboard.
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.
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.
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.
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.
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.
I do not think the current computers can catch up with Electron. When it is just one or two simple app it is ok, but when everything is built with Electron (which is happening now) then it is not enough even with 32gb+ ram.
My lived experience. Maybe bloated isn’t the right word, but attention to performance just isn’t there. Try using any swift UI app on iPhone or Mac. Try resizing a swift UI app window on Mac.
Yeah, it's not bloated, there are just a lot of surprising and weird performance holes, especially on macOS. Even on iOS there's dumb things like, if your List cell's outer view isn't a specific type, List won't optimize for cell reuse, and it will start dequeuing cells for every item in the List eagerly. Wrap your actual cell type with a VStack or something and it will work properly, only dequeuing visible cells. It can be really nice to work with, but man, some of the implicit behavior, performance other otherwise, is shocking.
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.
My recollection of current events at the time was that you were already having a dogshit experience using computers for many common things in the XP era with underpowered video hardware and trying anything complex in a browser, or Flash things with a lot of assets, so it's less forcing escalating a baseline and more recognizing the realities of what people were already expecting in a "good" computer and building thing that could take advantage of that.
I would agree it should have degraded much more gracefully and more readily than it did, but I'm quite confident we hadn't hit the point of minimal returns on improvements in hardware that would be necessary for such an argument yet.
Hell, I probably wouldn't make that argument until large amounts of RAM and VRAM (or unified RAM) are ubiquitous, because so many workloads degrade so badly with too little of either.
What does "GPU" mean here? Previous uses of the term seemed to imply "dedicated hardware for improving rendering performance" which the SVGA stuff would seem to fall squarely under.
The term GPU was first coined by Sony for the PlayStation with its 3D capabilities, and has been associated with 3D rendering since. In some products it stood for Geometry Processing Unit, again referring to 3D. Purely 2D graphics coprocessors generally don’t fall under what is considered a GPU.
It has been associated with 3D rendering, but given that things like the S3 86C911 are listed on the Wikipedia GPU page, saying "Accelerated GUIs don't need GPU" feels like attempting to win an argument by insisting on a term definition that is significantly divergent from standard vulgar usage [1], which doesn't provide any insight to the problem originally being discussed.
[1] Maybe I've just been blindly ignorant for 30 years, but as far as I could tell, 'GPU' seemed to emerge as a more Huffman-efficient encoding for the same thing we were calling a 'video card'
I don’t agree with what you state as the vulgar usage. “Graphics card” was the standard term a long time, even after they generally carried a (3D) GPU. Maybe up to around 2010 or so? There was no time when you had 2D-only graphics cards being called GPUs, and you didn’t consciously buy a discrete GPU if you weren’t interested in (3D) games or similar applications.
In the context of the discussion, the point is that you don’t need high-powered graphics hardware to achieve a fast GUI for most types of applications that WPF would be used for. WPF being slow was due to architectural or implementation choices.
Most people consider GPU to mean "3D accelerator" though technically it refers to any coprocessor that can do work "for" the main system at the same time.
GPU-accelerated GUI usually refers to using the texture mapping capabilities of a 3D accelerator for "2D" GUI work.
Calling that "the GPU acceleration" on Mac OS X was a bit overstating the things. It supported rotations, compositing, and some other bulk operations, but text and precise 2D graphics was rendered on the CPU.
It _still_ is not trivial to render high-quality 2D graphics on the GPU.
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.
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.
The promise was that WPF would use hardware-accelerated libraries such as DirectWrite to put text on the screen even faster than GDI+ (using the CPU) could do. The reality turned out to be quite different: multiple layers of abstraction and just plain inefficient WPF code [1] meant that users needed powerful CPUs and GPUs just to get reasonable performance.
I had an Xperia for a while but kept my iPhone and then installed the iOS 26 beta on it. Expectation was that it would run but be pretty painful. Surprisingly, even the beta ran so fine that I sold the Xperia and switched back to iOS. And it's still my daily driver.
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.
That may be how JavaScript started, but unless your claim is that JavaScript hasn't changed at all in the thirty years or so since then, your argument is a complete non-sequitur.
Yeah, thank you. Also, JavaScript today means TypeScript—an arguably extremely capable type system actively developed by Microsoft—and several, modern runtimes with a big standard library and solid asynchronous primitives. There are a lot worse scripting languages out there.
Folks misunderstand the whole point just because I mention TypeScript. Sure it’s a capable and elegant language. Doesn’t change the fact that it’s a bloated monstrosity on the desktop.
Think about it: it transpiles to JavaScript. Even if it’s the most elegant language in the world doesn’t change the fact that it’s a world of bloat.
Stacks on stacks on stacks. And yet people are complaining about .Net? Come on. Lol
Transpilation and bloat are orthogonal. Javascript being bloated or not is also a relative: consider Python, which is much slower than js, and much more memory hungry.
To further argue your original point: chrome & electron are the only reason desktop is still around, both Microsoft and Apple tried their very hardest to build a walled garden of GUI frameworks, rejecting the very idea of compatibility, good design, and ease of use, until they were surpassed by the web, and particularly Google, showing that delivering functioning applications to a computer does not require gigantic widget libraries, outdated looks or complicated downloads & install processes, but is in fact nothing more than a bit of standardization and a couple MBs of text.
All this electron & web hate is so incredibly misplaced I don't even know where to begin. Have you tried making a cross platform mac/win native app? I have, its like being catapulted into the stone age, but you're asked to build a skyscraper.
Why would transpiling change anything? C++ was once transpiled into C. I appreciate that you personally think JavaScript is poorly designed (I mostly agree!) but that doesn't mean it's slow. V8 can do miracles nowadays.
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 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.
Sure, if we ignore the stuff and bugs they still have, the missing features in SwiftUI and performance regressions, or the iPhonisms brought to macOS with Catalyst.
The reboot of frameworks based in OpenGL with the Metal rewrite.
And many other things I am not bothering with since all those OS System N releases, A/UX UI framework, Teligent based documents,....
If Apple products are so compelling why are so many devs using Electron, React Native and Flutter on macOS, to the point it deserved being mentioned at WWDC 2025 State of the Nation Keynote?
My point was don't throw stones when having a big glass roof as well.
Apple isn't the perfection you make out to be, also has a rich history of failures, and only did not went bankrupt due to sheer luck of doing the right decision when there were not many remaining to take.
That's a different issue. Things like Electron are popular not because native development is buggy, but because most developers these days are web developers. They know Javascript. They've never written anything in C/C++ or even the slightly friendlier Swift, Rust, or Go. Electron lets people who only know the Web make desktop apps.
> If Apple products are so compelling why are so many devs using Electron, React Native and Flutter on macOS
That is not how the decision making for cross-platform works. You choose those alternatives knowing that they are crap in many respects, yet accept the trade offs because you want to save money on dev hours.
That’s not the point being argued either, nor it being perfect. It’s just about Apple’s UI frameworks being more coherent and consistent across all their own platforms, unlike Microsoft. Even Android developers who’ve done a bit of work on iOS easily agree that Apple’s SDKs are far better designed and behave more predictably than Google’s.
This one caught me completely off guard when opening YouTube the first time on an iPad: Accidentally clicked on a wrong button and got stuck in a "please subscribe to premium" modal. No amount of swiping or tapping outside the popup would help, only thing left was killing the entire app.
This experience put a major dent in my perception of the "Apple has the most intuitive UI" narrative.
The YouTube app has non-standard and nonsensical UX on every platform. It's Google's fault, nothing to do with Apple.
Case in point: The YouTube app for Apple TV. Everything (pausing, playing, changing subtitles) has been done opposite to the standard player found in every other app. You cannot use the main button to pause and resume, for example. Recently they broke swiping. Normally, you swipe the remote to navigate between UI elements such as squares in a grid or in lists with a light touch. It's very fluid, like a touch screen. But the YT app has added severe "inertia" to touch gestures, and you now have to "fling" your finger on the remote trackpad to navigate. Everything feels syrupy and stuck.
YouTube and Amazon's Prime TV app are the two worst apps I've ever used on Apple TV. I believe they both use some non-native UI toolkit that doesn't respect native OS conventions and doesn't even try to. Pretty incredible given the size and budgets of these companies.
The YouTube app does the exact same thing on Android. I ran into this just yesterday on my gf's phone, as I'd just added her to my family plan, tried to verify the settings on her phone, and it trapped me on an upsell screen for YT Premium that I had to kill the app to get out of.
Maybe just the circles I run in but these are not evergreen questions in my experience. I don't even know what "go back" is supposed to mean here, or for that matter what it would mean in a Windows application. Is there a system level "go back" in WinAmp/Excel/SimCity/Photoshop I've never seen before?
In iOS, task manager and closure can't be overridden. You swipe right to return to previous application. You can swipe left for a couple of seconds if you didn't intend to do that.
You swipe up and remove the application from the stack, all processes of the application is killed.
Background processing has strict limits, and you need permissions to run longer than that, and for some use cases, there are no recourse. OS swaps you out or freezes the app.
If you want an app to work in the background, don't kill it, period. Push notifications are handled by the OS and is not hindered by this.
I'm not using Reddit in any capacity since they have started giving their content for LLM training, so I can't help you with that, but looking at 4-5 third party applications right now, they all have a left arrow at top left to go back.
They all are very different applications and have very different designs, yet the arrow is there.
To be honest, I baffled at your question for a second or so, because I never thought about that, yet the method is so universal that I was not thinking about it at all.
I feel that some people are just too old to get used to the swipe based ui. I mean friends of mine who just keep buying the only phones with (screen based) back and home buttons.
It's not just that you need to get used to gestures, it's that they are not discoverable at all, and that they can be awkward to perform with mobility issues, old hands, short fingers, etc. It's easy to make the wrong gesture, eg. the phone detects a swipe down instead of left to right, more so if you are holding it in one hand, so it's finicky and frustrating to have to rely on it as the only way of doing a common action. Why is it so wrong to have a simple navigation bar, it doesn't take up any more space than the hideous notch at the top?
It's not "getting used to", I feel like that gesture is less practical. It involves or using the "circle" to assist on how to use the gesture (creating a black void on the screen that you need to plan your use of the phone around) or having the swipe that 1) is not as reliable in my opinion and 2) can be triggered accidentally
For me is like claiming that touch screens on cars are the future and people are too old to get used to it.
Maybe saying "too old" is disrespectful indeed, what I meant was more that my kids grow up with swiping everywhere but we grew up with (hardware, then touchscreen) buttons and the older we get the harder it is to get used to new use paradigms.
Swipes are of course nice because they allow for the same interactions without taking any screen real-estate. And I have to say it quite consistent across the iOS apps I use.
I could get used to touch gestures if they were more consistent and tolerant enough for wrong inputs. It may work in one app but not another. One app expects me to swipe from left to right to go back, another wants me to swipe from top to bottom for the same thing. It may mark an email as unread if I start the swipe a pixel too far away from the screen edge. On Android swipe gestures may vary even on different phones from the same brand.
In iOS, tapping the top edge of the screen means scroll to the top. Except in the Photo app, where it means "scroll to the top of the current section, or almost the top, or do nothing and make the user guess if they just tapped the wrong way".
Meanwhile when there's an X button or arrow to the left I always know what it's going to do aside from one or two overly creative Android apps.
I feel that some people are just forgetting what the reason it's easy for them is because they learned that "swipe based UI" ages ago.
When I get handed iPhone I have no clue on how to even open an additional tab in Safari and any finger gestures do not do the things what I expect nor there is a lick of indication on how to do something. It's all just a memorized magical incantations at this point. But hey you are familiar with them so it's easy to bash on everyone who is not in yours eco-system.
Is that what's going on? So many touch gestures seem to rely on landing in the right 2mm diameter area, but the minimum reliable resolution for touch seems to be a 4mm diameter circle. It's even worse for my father, even though cognitively, he would have no trouble understanding the hypothetical requirement. It's also noticeably worse during the depths of winter.
Hmm, would explain that frustrated pokey interaction I see elder people often throw at touchscreens... you know, chin up, peering down through their reading glasses, going for a 4th, 5th try at something...
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.
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.
True, but: Microsoft haven't made a better UI framework that's portable to Windows yet. Everything after WPF has near zero adoption, including (critically important!) by Microsoft itself.
Mono used to have libwine embedded. You know, libwine exists as a library running and compiling Win32 natively under Unix. Instead of PE binaries you would run ELF Linux ones, but with nearly the same outcome.
Every time I tried following alone with the winelib/winemaker documentation, I always ended up with an ELF that had to be invoked using "wine" to run. Nothing that could self-load any of the wine dependencies.
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.
The size and losition of the traffic lights control is not dependent of the os the app runs on but on the os the app was compiled on. So things are not updated across the board
It’s still dependent on the OS it runs on AND the SDK it compiles against (not the OS it was was compiled on).
But that is legacy bridging behaviour, and is not compiled into the app. Apple can and do change those with time.
For example apps that compile against macOS 15 are not opted into Liquid Glass when run on macOS 26 but will be once on macOS 27 according to their transition docs.
I don’t think Microsoft’s approach to perpetually support old apps is unequivocally a good thing. It seems to be getting them into a deeper and deeper mess over time.
As a consumer I prefer Apples approach. If I were an industrial customer relying on old software to operate my machines i would prefer Microsoft’s approach.
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.
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.
All the various windows UI frameworks are stable, but not supported and not receiving new updates.
That's the problem.
And what makes matters worse is because of all the shifts, the documentation throughout MS is in just varying states of outdated. For example, this document which recommends using UWP [1] to handle high dpi problems. But of course, UWP (which was the right way to do gui in Win 10) is now defunct for win ui.
WPF is also stable. Microsoft's UI strategy is similar to keeping all of Motif, GTK2, Qt5 alive while engineering new stuff into Qt6 without deprecating anything.
Btw Linux UI is not by any measure stable. It is the furthest thing from stable.
I'm still using Win32 (via WTL) to write a developer focused application, but I know that someday I will need to switch to Qt, dear ImGui, or develop my own UI abstraction layer.
The biggest disappointment has been that all new OS features require a new runtime and are not accessible from just pure Win32 any more. Heck the pipeline for developing UWP/WinUI3 apps requires extra steps to register and install the application just to run it inside a debugger.
Various versions of GTK which introduced breaks but didn't really change the core philosophy of how you build a GTK app. IMO, this is the preferable way to evolve an ecosystem.
The problem microsoft has is instead of making "Win32, but with these extentions or these APIs removed", heck even as a separate "framework". What they did instead was "You know what's hot right now? XML. So let's make an XML based UI framework. Actually, it's javascript and css, so let's do that. Actually, people really like electron so let's do that."
That is to say, it is possible and I dare say easy to migrate an application from GTK 3 to GTK 4. It's basically impossible to migrate a WPF app to UWP. You have to rewrite the whole thing.
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
Yeah, especially funny since they had the early lead with their iPaq PDAs and Windows CE. Which they completely squandered by ignoring them.
Then they acquired Nokia that already had an almost-ready ecosystem of apps, with good snappy UI. And then spent two years building a (shitty) framework on top of the long-neglected Windows CE kernel. Which was known from the start to be a stopgap solution before they port the full WinNT kernel.
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.
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?
Sure it is a hassle to get notifications working, but my take on that for years as a desktop user was "I need another source of spam about as much as I need to get raped". For years I had bottom of the line Android Tracfones and wondered "how is it people get so excited about apps?" because they just didn't work but once I got an iPhone I started to appreciate that the McDonald's app would send me a notification when my food was ready. Recently it was pointed out to me that the application behind these cards
really would benefit from notifications ("your photos are ready!") and I am looking at the hurdles I can jump through and it looks possible but weird. Like why would I want people to install my app on the homescreen where it will get lost on page after page of twisty little app icons that all look alike?
Then there is that PWA boondoggle, there is another app in that system that I can use to register those cards and it is a clear case where I might want to do it outside of cell coverage (say I was in the woods) save a form submission and upload when I get back in range.
What can I say? That service worker system is insane, something like Kubernetes that only Google could subject us to. I mean, Google could have worked out the math for synchronizing a local database to a remote database, by then the Lotus Notes patents were mostly expired, we could have gotten something good. Or Google could have added an API to control the behavior of the browser cache. Instead we got something half baked and barely reliable and then Apple went out and made something a little bit worse. Had it been a good standard to begin with the outcome could have been entirely different.
I 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.
The inconvenient truth here is also that following the system theme is an anti-feature for most apps. On the desktop, you want your app window to be recognizable at a glance, meaning the primary color should be the brand color, etc.
I currently have open Chrome, Spotify, Discord, Aseprite, and Zed. All of them look completely different, and that's actively helpful for me, the user.
It's nice to follow the system's light/dark setting, and obviously the behavior of basic UI controls should be unsurprising, but beyond that there's no point in "consistency".
This. So often features to use system colors can cause apps to be unreadable or just look like crap. The first time I get a bug report that people can't read something I will lock the colors the down, I just don't have time for that.
Who says the system theme is well designed at all? Back in the 1980s you could count on most text color combinations on a Commodore 64 or an IBM 3279 or a PC with a CGA working.
Today it is absolutely normal to type
ls
on a Linux machine out of the box and if you are running X or Wayland some of the file names are dark blue on a black background and completely un-readable. To be fair, if you are logging into a Linux machine on Windows with ssh on CMD.EXE or most terminal software you get similarly poorly chosen colors. (To be fair, MacOS does do better!)
As a web developer it pisses me off because I am expected to follow
and regularly my management gets legalistic looking documents from customers complaining that we only have 6.5:1 contrast on something and you know what I do... I fix it. I wouldn't send anything to my tester that was unreadable and if I did I'd expect her to put in a ticket and I would... fix it. When MUI computes the coordinates wrong and something draws 20px right of where it should be... I fix it.
Whenever I've put similar tickets to the various parts of the Linux desktop mafia they close it as "won't fix" and often give me a helping of verbal abuse. Even Microsoft occasionally fixes something (even if half a decade late) and their people are polite.
yea there's so many ways through this now. golang and wails is great, rust and tauri is great. both seem to not feel like the slug that is electron because they just use whatever os native web view your os has.
for the dedicated more native stuff dioxus is kinda cool if you don't want a web stack in the mix.
i'm enjoying golang and wails though paired with whatever front end i want, all apps i've made perform execellent on windows. bottom line = yeah i can't really think of a scenario where i personally would ever write an app for windows specifically.
i, like you, used to get hung up on native vs web framework. i'd encourage you to give it a go, possible you cede that mayhaps the native thing isn't as important as you thought.
The DOM is very ill-suited for most UI. Too complex and lots of missing features. It’s a whole bag of unneeded code and the resulting UI doesn’t fit anywhere.
> The DOM is very ill-suited for most UI. Too complex and lots of missing features
Can you expand on this, because I'm not seeing it myself. The DOM, html+css is very flexible. It easily encompasses most UI. Most UI is some kind of data display, so lists, trees, tables, forms.
The need for JS might be what you're complaining about. I think we might be stuck with it as a UI control language forever.
The DOM(and CSS) is primarily built for documents and forms, even with the latest addition like Flexbox or Grid layouts. It is closer to typesetting tools like troff, latex, texinfo than any UI engines you can think of. And some that are not needed, like the difference between <i>, <a>, <span>, <strong>,...
Also with most GUI frameworks, there's some difference between widgets like label, button, menu, checkbox,... and containers that does layout management. And there are not a lot of elements in both sets. This is the reason why React Native has a very sparse components library. With simpler implementation, you have a simpler rendering path, and the developer have less elements to deal with.
Also some have ready-made implementation of really useful widgets, like tree, grids, tables, lists, and other dynamic things. You can find libraries for those on the web, but the web implementation of scrollable container is janky.
The GUI system for the NeXT was based on the Display PostScript system which in turn was based for the PostScript system designed for rendering to printers. Quartz in MacOS X is a further evolution of that.
Inside HTML 5 you can find facilities for rendering documents and you can find facilities for rendering applications, including those forms. There is not a clear line between one and the other.
PostScript was for rendering graphics to a printer with a good emphasis on texts. Most of HTML is about marking up and styling interactive documents. There’s no clear line between the two, but an API for applications UI has different goals than one for document typesetting (even interactive one).
HTML have a lot of tools for devex, but if you’re going for a good codebase and simple implementation for a desktop application, QT is way easier.
> 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.
I know one of the GTK developers who dropped out of my research group in the 1990s who's been in charge of triaging tickets and he's the kind of guy who doesn't care if there is just 1.05:1 contrast between text and background and will refuse a one-line patch to make menus render right in rootless X windows because he wants to punish you for doing things in a way he thinks is wrong.
And he probably wonders why it is never "the year of the Linux desktop" but hey it is OK because Red Hat Linux is something enterprises subject their users to and if it had the slightest bit of flair customers would complain.
So when I hear GTK I think Nein Danke!
In general Linux has the kind of fanbois problem that MacOS had maybe 10 years ago. There are so many things that still "just don't work" after years and they never get fixed because you can live without them. For instance I can tell you how to install some package like
sudo apt-get install mypackage
and that's all! I can make 10 pages of screenshots to tell you to click and click and click and click and click to install "mypackage" with the GUI [1] and you may wind up looking at a spinner for 10 minutes or longer (eventually you give up) and you might wind up corrupting your package database and not being able to install or update anything until you look up how to rebuild it. The Linux desktop is stuck with having done the 20% of the work that gets it 80% done and never does the rest of the work because you can use the command line anyway.
[1] and you still might misunderstand it and need intensive tech support
Interesting, at first pass I’d say the source availability has little to do with the topic at hand. But on second thought it might be rather significant. No company would finance making 2x identical cross platform apps, but if you have a pool of OS folks who are free to contribute at their leisure, the calculus changes a bit.
But isn't the whole point of linked article is that author doesn't like regular apps because it lacks control over UI and functionality compared to Web apps?
Being open-source is kinda even better in that regard.
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!
I am a Firefox-first developer, almost everything I write works in Firefox/Chrome/Safari without a lot of drama.
I have one application at work that loads a table with 40,000 rows into a data grid that works really well on Chrome and lags on Firefox, that's the one case where the performance difference matters.
This year I've been interested in biosignals applications that read data with the Web Bluetooth API and Web Serial API which are ordinarily Chrome-only. I was about to get one of my junk Android tablets out of mothballs when I found there is Bluefy for iOS which supports the Bluetooth API so I have no problem going to labs where they have a really klunky HRV system based on a PC and show them something sleek on my iPad and in 20 minutes i can demonstrate to you, with your own physiology, everything you actually need to know out of a big review paper on HRV.
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.
One could (and I would) argue that they achieved that despite their web-tech-based UIs, not because of. At least those of us who were around for the days when most apps were still native, do notice and get bothered by the input lag, for instance.
Slack is, in fact, one of the worst offenders. It is so incredibly sluggish. And it doesn't need to be, when I compare it to the speed (and memory consumption) of Pidgin with the Slack plugin.
Async comm in web apps often keeps them responsive when the native app experience is: spinner... spinner... spinner... spinner... lock up the window and you can't move it... spinner... spinner... spinner... "should i reboot the whole machine first thing or should i try killing the app with task manager and starting again?"
Their killer feature, being able to share a link with anyone at the company and instantly collaborate (live!), is made far easier on the web platform vs native. “The input lag” frankly does not matter in the big picture, imo.
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.
This makes sense, because even in the best times Windows was not the biggest money maker for Microsoft, it was Office. So MS was never fully behind Windows, it was only the means to an end, which was selling the most software for enterprises.
Ironically, Office was the original poster child for Microsoft reinventing it's own widget toolkits, even back when Microsoft had a coherent visual design and developer story.
Because their strategy for getting their applications in front of everyone has always been to get Windows in front of everyone, and that meant having to support third party applications that they chose not to try to incorporate into their own apps, but which got enough usage that not supporting them would mean losing those Windows desktops, and thus losing those users of the MS applications that were on every Windows desktop.
It's quite possible that this attributes too much intentional strategy to MS, and also treats them as a single entity with a single strategy more than they deserve. The MS internal teams that were bending over backwards to maintain backwards compatibility were not the same as the teams that were churning out new APIs, building Azure, etc., and quite likely had very different incentives.
Microsoft was a language company at the start - they had a huge share in 8-bit computers and their BASIC made into the ROMs of almost every computer sold in the 70s and 80s. Then they branched out to applications, with little success (I remember Multiplan on CP/M, DOS, and Mac). When they started selling PC-DOS and MS-DOS they had no applications play to speak of. Office only came much later, and the apps that appeared for Mac, Word and Excel, were ported to Windows starting on Windows 2. Word for DOS struggled in the market and never reached a significant share.
In the sense of being marketed as a single integrated package, yes, I agree. I was using the term loosely to refer to the apps themselves (Word & Excel were the first two, as you note, the others came after).
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.
That was such an amazing mission statement. It was a real measurable goal, and progress towards it was quantifiable. And Microsoft actually did it! That mission statement drove actual strategies (lower costs, don't complete with Apple on the high end, force OEMs to compete against each other on price, etc) that resulted in its ultimate fulfillment.
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.
He had a strategy and it worked very well. But every strategy must be updated. It's basic BCG matrix stuff every MBA graduate knows by heart: sooner or later your star product becomes a cash cow and then a dog. To keep your company growing, you need to identify your next potential stars among question marks, boost them with cash from the cash cows, put competent managers in charge and remove those who get in the way.
Gates did this with Windows, Office, XBox among other things. Ballmer failed to do this this with Windows Phone. Nadella did it with Azure, but he needs to do it once again with AI. You can see that he's pushing hard with Copilots everywhere, what's missing is a manager that has a coherent vision of what AI at MS should look like. ScottGu is in charge of both Azure and AI at MS, but I don't know if he can deliver.
I agree with most of that. To be charitable to Nadella, at the time he first came into the role, Microsoft needed someone yelling "Cloud! Cloud! Cloud!" because the company was certainly behind folks like AWS. But for a long time he basically stopped there. Office migrated to the cloud and they pushed out Azure. Then he went on the AI rant and they decided that putting AI into everything, whether customers wanted it or not, was "the next thing." But now we're learning that Azure is a steaming pile of crap with customers leaving, and this article about GUI strategy shows they don't have an application development strategy. Everybody is fed up with Windows. Everybody is fed up with all the numerous "CoPilots." You actually have regular people investigating moving off Windows to Linux desktops. The one thing that Microsoft did exceptionally well through the 1990s and early 2000s was keep enterprises and app developers moving in the same direction. They bent over backwards to keep old Windows 3.1 applications running even on Win32 systems. That all ensured that nobody questioned whether they would work with Microsoft. They were the default and they commanded huge market power because of it. But that's all changed, and they have nothing to replace it. With everybody starting to ask questions that Nadella doesn't have answers for, it's going in a bad direction. Nadella needs to call his EVPs to account and force them to make some hard decisions about what lives or dies and then pressure test the resulting strategy with his customers, both old customers and potential customers. Surely, cloud and AI are a part of that future strategy, but he needs to figure out the rest of it.
In theory, the market should be pricing in based on future potential. As it has become increasingly clear this past decade, the market is not rational.
But I compared it to sp500. Even QQQ only 6x’d in that timeframe.
Which bubble are you talking about? Even if you remove everything after January 1 2020, it’s still up 4x since nadella took over. And that follows a decade of stagnation under Balmer.
What numbers do you know of that show that Microsoft hasn’t been successful since nadella took charge?
Complain all you want about the products, but the stock under nadella has been a success.
Stock price going up is not the success criterion for a business. Making money is. And Microsoft's decisions are undermining their ability to make money in the future, which makes them bad decisions even if the stock price has gone up or if they make more money in the short term.
> Stock price going up is not the success criterion for a business. Making money is.
Microsoft’s net income is up roughly 5.4x from ~$22B in 2014 to $119B today. Profit margin also expanded, from ~25% net margins in 2014 to over 36% today.
Sure, but how much of that had to do with the design and implementation of Windows? You know, the OS that runs half of the modern economy. Microsoft is just milking it without a coherent vision.
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.
Most probably it was on purpose. MS is famous for the infighting of internal groups and how the management doesn't know how to control their divisions.
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.
Nope, it wasn't solved in UWP days, neither it's solved today.
To satisfy my interest, I've tried creating WinUI app (aka UWP/WinRT) in Visual Studio 2026. And this is what I've got on the first app launch after compilation:
"This device needs to be set up correctly to develop this type of app for Windows. If you don't, then you can't install and test your app before you submit it to Windows Store"
I don't want to install/submit, I just want to be able to run my fricking .exe. Period.
So why are you calling this issue solved? To me, it's still right there in the plain sight - the same voodoo dances and delusional expectations of subordination to Windows Store.
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.
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.
They did pull that rug, twice, in two different directions.
1) VB7 (VB.NET) entirely split the VB developer community.
2) VB6 IDE has not worked well and is entirely unsupported in every Windows after XP. It's generally recommend to build VB6 apps in an XP VM and XP being out of security support it's now a huge "Use at your own risk" and "Do your best to isolate the VM from ever having an internet connection". (Not to mention that installers like Install Shield that still understand VB6' super messy version of COM are generally also out of support and security support.)
It was alleged that Microsoft almost dropped the runtime components for VB6 in Windows 11. It starts to feel like only a matter of time before they do.
Definitely not, since it actually takes quite a lot of red tape to ship something as ancient as MSVBVM60.DLL in Windows 30 years later, and guarantee that it is still working.
It's just that it's a piece of tech from back when Microsoft corporate dominance on the desktop was at its peak, and many large companies bought into the then-current tech stack, including VB6. So now Microsoft is stuck maintaining it because those are the customers that bring consistent revenue.
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).
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.
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.
They thought after V8 the performance was going keep improving and reach native speeds, they didn’t understand that the major performance wins were all upfront and it would hit a wall.
> 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.
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.
It's that Nadella doesn't really care about Windows, even though the kernel is the root of Azure. In addition, all the newer gui frameworks abandoned RAD interface. That is what made and still does make Winforms and WPF popular.
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.
The UI part is exactly what I meant. WinForms was a godsend for professional developers making line-of-business apps, because previously if you used first-party dev tooling, you either had to deal with the considerable limitations of Visual Basic, or you had to deal with MFC that was low-level enough that all the things that were tedious about Win32 remained tedious. In comparison, Borland had Delphi, and there was a good reason why it was so popular back in 90s and early 00s, and why Microsoft ultimately acqui-hired its main designer specifically to work on .NET (and it very much shows in the design of both C#, which owes as much to Component Pascal as to Java, and of WinForms, which is so similar to VCL).
With WinForms, we actually got something that was convenient without shackling you. And the whole cross-language story was great, too, especially around .NET 2.0 - with C++/CLI you could very easily wrap any random native code C or C++ library for consumption from .NET, with end-to-end integration in the build system, IDE etc.
Eh, WinForms did a lot to make Win32 UI accessible and usable -- especially layout and easy customization -- but I have to differ on the cross-language story. It was great, IF you were making primarily a C# program that happened to use some C/C++ components.
From the native code side, it was not so great. The .NET 2.0 CLR had very poor support for hosting from the native side and really wanted you to make a program that was .NET first, it didn't work well if you wanted something like primarily a C++ program that hosted a C# UI in the same process. Reverse P/Invoke via native exports wasn't exposed, so creating DLLs for consumption by non-.NET programs was difficult. Mixed mode debugging was and still is painful, with the debugger being glacially slow at some operations like OutputDebugString() processing and blocking some native features like data breakpoints, and the CLR eating access violation exceptions from native code so they couldn't be debugged properly. Build-mode wise, we had to ban C++/CLI assemblies depending on C# assemblies because the C# project system didn't handle incremental builds properly and forced the dependent C++ assembly to rebuild all the time.
These issues still largely exist and are an issue with WPF. It's a great UI framework, but it's unusable unless your front end is primarily a C# program.
(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 :)
> 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.
At the risk of getting my Microsoft history wrong, I'm fairly sure that Steven Sinofsky wasn't working on Windows or even MFC (i.e. what he did as one of you guys) in .NET's early days of 1999-2003. He was leading Office at that time. Office of that era was transitioning from the Windows XP look that still persists in Windows Forms to the early Ribbon, and was then (as now?) using very custom GUI code that didn't correspond to any specific higher-level Windows app framework.
Mac OS Office apps had just separated their codebase again from Windows apps after being unified in the mid-90s to get to feature parity (which annoyed Mac users who felt they now had non-native-feeling apps that were slow and bloated), and the "Office framework" was still quite distinct from any single-platform Windows app as a result of that.
So if Sinofsky did not understand why people went from USER/GDI to WinForms, that may just have been the fact that nobody working for him had felt the need to make that transition.
> What actually happened [re Windows RT, but I think the point applies to UWP in general] 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.
The fact that UWP XAML was its own new thing and not a extension of an existing Microsoft GUI app framework like WPF was not necessarily a "we hate managed code" thing, or even a "we hate those guys who invented managed code and want to screw them because we're Windows" thing. After all, .NET managed code had equal access to UWP through the .NET WinRT projection!
And to me at least (I didn't work on UI-facing stuff in Win8), it was absolutely conceivable that UWP could have just delivered Windows Phone 7 Silverlight's version of XAML to native code apps, with a thin adaptation layer to let even unmodified WP7 app binaries run on the desktop Windows .NET Framework with the WinRT projection and to allow slightly modified WP7 apps to look good in landscape mode on both Windows 8 and WP8. If we had done that instead of making UWP XAML its own thing, and if we had integrated the Windows Store with the Windows Phone Marketplace from the beginning so that Windows and Windows Phone apps could be sold as variants of each other through a single Store/Marketplace product entry on Windows 8 GA day, then I think we could have brought a lot of people forward who were already making good WP7 apps, and the Store wouldn't have been so empty.
Furthermore, IIRC much of the original UWP XAML implementation was done by the original people who built WPF and Silverlight the first time, and they would have known what they were doing in separating UWP XAML from Phone Silverlight. That they didn't go in the direction of extending Phone Silverlight was not necessarily shortsightedness on the part of provincial Windows people. Maybe they thought Phone Silverlight actually demonstrated fundamental limitations of WPF or Silverlight XAML or the Silverlight "coreCLR", or they wanted to make breaking changes as lessons learned from Phone Silverlight, which was put together about as hurriedly. (Windows Mobile 6 -> Windows Phone 7 first previews = 1.5 years; Windows 7 -> Windows 8 first previews = 1.5-2 years, tending toward 1.5 years if you account for the frantic re-planning after iPad came out in early 2010.)
> 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.
It's important to remember the specific reasons why Windows RT 8 chose to not support third-party desktop apps. The most important aspect of "iPad compete" that we wanted on Windows for ARM was not "all app UXes look and work well on touchscreen tablets" but "you can't ship malware, not even by rebuilding your x86 malware from source." Thus, every 3rd party app on Windows RT would have to live in the AppContainer sandbox that UWP apps are in by default, and the requirement that you ship through the artist formerly known as the Windows Store would be a second line of defense against malicious apps. And with the forced-enabled Secure Boot, subverting the user-mode controls by secretly installing a bootkit would be hard even with physical access to the PC.
Even within the Microsoft world only, Windows Phone 7 had proven the success of this approach of locked-down apps only available through an app store that checked apps on submission and afterward for security. It was not unreasonable to think that similar lessons might also benefit users of "big" Windows, which is why Windows 10 and 11 have the opt-out "S mode" which defaults to the Windows RT restrictions.
I do wish though that Windows 8 had learned different lessons from WP7 (about which more in another point).
> 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.
fair. but that struck me as strange even then. if anything, visual studio should have adopted the all-lowercase typography of the original metro-style design language from zune and windows phone 7, not AN ALL-UPPERCASE ONE.
Perhaps that was just another way that Windows 8 Metro-style apps' design and developer platform was like Windows Phone 7's Metro style, yet different in seemingly gratuitous ways. That is something I would attribute to internal Microsoft politics. Steven Sinofsky and Terry Myerson (leader of Windows Phone at that time) never really got along, and in the Microsoft philosophy of that era where engineering divisions were completely locked down from each other by default, that rivalry would have discouraged what little natural collaboration would have happened anyway.
> I 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.
I think the real mistake there was not so much that a particular projection of the Windows Runtime was stopped, but the more general idea that developers should be forced to consume what became known as the Universal Windows Platform or author custom WinRT components through only Microsoft-made WinRT projections.
In the name of winning over new or inexperienced Windows developers with "simpler, safer" projections, we in the Windows division almost completely failed for about 5 years to document or even explicitly say that WinRT was essentially just "COM: The Good Parts, Version 2012". (Martyn Lovell's Build talks on the origin of WinRT were a notable exception to this.) This discouraged people from using their existing COM skills to develop Metro-style/UWP apps or to gradually adopt features from UWP APIs that were accessible to them in their existing desktop apps. Other people have written that "WinRT=COM" thinking is actually a bad idea because it forces people to deal with COM and its more annoying ideas (separate IDL etc.); I disagree because we should have reached out to people who live in COM world to get a ready developer base.
That mistake was a key part of the still larger mistake you touched on of trying to make the UWP and desktop worlds 2 completely different developer platforms that happen to co-exist on the same desktop edition of the Windows OS. That was the key "we didn't listen to developers" mistake that set up UWP for its market failure. Another example: Even today, you can't adopt the battery-friendly UWP app lifecycle using Windows App SDK, which is supposed to be the UWP successor for desktop app developers. So much for WinAppSDK (or indeed UWP/Metro-style apps in Win8) enabling a true no-compromise user experience.
It took real tours-de-force like Kenny Kerr building C++/WinRT and blogging about it, Raymond Chen blogging about using WinRT APIs through the unprojected "ABI" interfaces, or the VideoLAN organization building a Win8/Win10 UWP version of VLC in C, to get the word out that the UWP world wasn't some alien thing with dark magic that only Microsoft wizards had full access to. And it doesn't help that the wizards really do have a few special powers that they jealously guard even now.
> 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.
That was at least in part due to the aforementioned obsession with iPad and generally mobile. One thing that Sinofsky is not wrong about in his post is that the classic Win32 app model is not conductive to good battery life - there's very little there to properly handle things like automatic background suspension or low-power push notifications. WinRT was designed with that in mind, but that would make no difference if the apps would just ignore it, hence the heavy-handed push for WinRT apps only (AFAIR it wasn't restricted to Store, although you had to jump through some "developer mode" hoops to deploy apps directly).
The main reason Win32 can't handle automatic background suspension or low-power push notifications is simply that those features haven't been exposed to it. There's nothing preventing a Win32 program from receiving those types of notifications and then being force-ended by the OS if it doesn't respond in time.
When I first started porting programs to Windows ARM64, I didn't have an ARM64 device and had to test in QEMU. It ran extremely slowly, probably 1/50th of real time. All UWP programs like Calculator ran like a slug. But which programs still ran reasonably? Classic WinDbg and Task Manager. Two programs that were still plain Win32.
There are significant issues with Win32, namely its lack of a permissions and isolation and lack of hardware acceleration in the old windowing UI (User/GDI). But the idea that Win32 is inherently power inefficient is, IMO, just BS. Its roots go back to CPUs that were orders of magnitude slower than modern CPUs and there is nothing difficult about making a Win32 program that idles at 0% CPU when not in use.
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."
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.
The .NET JIT compiler absolutely does query CPUID flags and generates different optimized code depending on available features, as well as the performance profile of each CPU model. This is similar to always passing `-march=native` to GCC.
This can have a huge effect on a wide range of applications, not just those using particular CPU features. For example, each libc implementation typically has a separate implementation `memcpy()` for each set of CPU features.
> 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.
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.
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
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.
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.
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.
Agree, and this is my point. Apple absolutely has a very clear message on how developers should make software, but as you say, developers often do not care.
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.
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.
They've got unified themes that make GTK and Qt applications look nice alongside each other. Users who care will be using those. Users who really care might refuse to use your application because it isn't the toolkit they like, but you shouldn't lose sleep over satisfying such particular and demanding users. They're not paying you anyway.
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?
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:
You might have sold me on this, because on top of the productivity-ish stuff I do, I'd really love to get into VST development. If I hadn't fallen into Photoshop plugins first, I would always have been an audio plugin dev. I loved PSP VintageWarmer in the late 90s.
The UI in Rowland's demo at 32min is feeling a little DearImGui / Reaper-ish, kinda bland while also being non-native. But I've seen all the UIs that Arturia & everyone else makes with JUCE, even what Valhalla does with it with their NASA inspired interfaces, so it can clearly make amazing stuff.
I can't believe we're now looking to PACE of all companies to help indie devs. I hated iLok for so long even though I have two iLok dongles now ;)
Well, I hope you will take a serious look at it as a technology stack worth learning, because when you get things rigged up so that you can really just push your changes into a repo and get the builds for all platforms, its some kind of magic, and you will - most likely - be really inspired to create something great.
Which, I hope, you do.
(PS; - the default UI skin is, imho, intentionally a tad bland in order to promote developer uptake of JUCE' pretty amazing skinning/UIBehaviour system...)
I think I prefer that JUCE is a one-off licence at $800 (for small business) and that they offer a 30% discount if you want to upgrade when they release a new major framework version. I'd rather not get locked into Qt's annual $618/subscription every year just to continue distribution & development.
But Qt has the bonus of also running on HaikuOS, and I've definitely seen more business apps in Qt (pretty sure 010 Editor is Qt).
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.”
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...
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.
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.
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.
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.
> 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.
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.
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.
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
I've worked inside the Microsoft 365/SharePoint ecosystem for over 20 years, and the incoherence runs deeper than the GUI layer.
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.
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.
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.
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.
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.
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.
The end state of genAI could as well be a few billionaires being their enterprise and everybody else being unemployed or working at the factory. Robots are not there yet (far from it) and someone needs to build and maintain the thing as well as food for everyone. High unemployment could drive salaries down and make lots of thing unavailable to the common people while making humans cheaper than automation for boring manual work.
That's an extreme scenario but today's politicians are not very keen into redistribution of wealth or prevention of excessive accumulation of economic power leading to exceeding the power of the state itself. I see nothing preventing that scenario from happening.
> High unemployment could drive salaries down and make lots of thing unavailable to the common people while making humans cheaper than automation for boring manual work.
‘I wanted a machine to do the dishes for me so I could concentrate on my art, and what I got was a machine to do the art so now I’m the one doing the dishes’
But you already have a machine that can do the dishes. Like doing the laundry, people forget the machines they already have doing 90% of the work. Soon enough artists will forget that computers can do 90% of their work too.
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.
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 still visits Microsoft occasionally. A friend showed me a picture of him visiting Microsoft in Beijing a few months ago (he was excited about BillG visiting). So my guess is that he still has an interest in Microsoft products.
I couldn’t know, but generally speaking, older billionaires don’t typically interact with the world in the same way most of us do (well, those without a social media addiction anyway). The device is someone else’s problem.
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.
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.
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.
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.
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.
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.
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.
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.
That might have been more significant had the Windows Runtime not been effectively locked off to Metro-style apps. You could technically use it from a desktop app, but almost all of its functionality was only allowed within a Metro-style app, often due to requiring a core window or package identity. Even today the vast majority of useful WinRT APIs, including the entire UI system, require UWP or package identity.
Package Identity isn't that different from Signed COM Registration of the ancient past. Microsoft built up a lot of dislike from it by building it "sandbox-first", but the core of it still isn't that different from COM's ancient footpaths, at least to the COM diehards that hate .NET and didn't learn near enough from .NET's battles with the same things in terms of package signing, CAS (Code Access Security), and the GAC (Global Assembly Cache).
"Sandbox-first" even made some sense as a direction to work because it is harder to add a sandbox after the fact than to start with one, which is one of the core lessons learned from XP trying to sandbox some of the insecurities in Win32 and getting caught in a lot of complications. (The "sandbox-first" of UWP wasn't even that different under the hood from the XP "sandbox" of Folder/Registry Redirection, just a little better hardened.) Microsoft needed a lot better messaging up front if they had expected to allow more apps to leave the sandbox eventually. But Microsoft probably did believe the UWP sandbox was a better and safer experience for consumers.
But yeah, what's left of Package Identity outside of the sandbox feels like it includes several classic mistakes from .NET's CAS/GAC era, and also seems to point out that Sinofsky was wrong about WinRT "respecting the past" when it failed to learn from that era because it didn't trust .NET's history.
One significant difference is that Metro/UWP requires signing for pretty much everything. Without signing you can't have package identity, and without package identity, you can't even use the UI system. Furthermore, it requires a paid cert, which is expensive and requires publicly divulging your identity. I have major problems with this as it opens developers up to harassment. .NET at least allowed self-signed certs.
It's true that there is no great answer for how to add capabilities and sandboxing after the fact. But what Windows did was build an incredibly restrictive sandbox and then tell everyone who couldn't accommodate even one of the restrictions was "sucks to be you". The result was that developers, when confronted with "all or nothing" for Metro-style apps, were forced to choose nothing. It was also not a good look that Microsoft's own flagship applications like Visual Studio and Office did not show any progress toward adopting UWP, and in the latter case, was specifically exempted from the Windows RT restrictions to continue using Win32 on that platform.
If there had been a better strategy for easing in UWP technology, we might have seen better progress on adoption of Windows Runtime APIs and capabilities so new programs could gradually move toward the new technologies and away from HWNDs. Unfortunately, the technical barriers that were put in place between Win32 and UWP are so large that progress toward breaking them down in the Windows App SDK has been slow.
The GAC and certain CAS configurations would require paid certificates, too. Certainly the requirement of paid certificates can be seen as a part of how both of those eventually fell out of favor. That is another of the things I felt UWP missed learning from .NET. Developers do generally dislike code signing certificates and try to avoid them.
Also to be fair, UWP had a rather streamlined certificate system if you targeted only the Store and let the Store manage your certificate chain. It was even a little bit easier to use than Apple's similar App Store management of XCode certificates. Not that that was a high bar to clear.
> It was also not a good look that Microsoft's own flagship applications like Visual Studio and Office did not show any progress toward adopting UWP
There was some progress. Office involves a lot of teams working at different paces and sometimes extremely different codebases. OneNote was fully UWP for a while and was at one point considered a flagship and testbed for UWP "Fluent Design" (both before and after the shift from touch-first to the over-correction to "it's just a desktop framework that sometimes is touch friendly"). Several new Office apps were written UWP first, including the "Office Hub" app that became called just "Office" and now is even more confusing called "Microsoft Copilot 365 app". "Outlook (New)" has always been React Native, but as a React Native project, it ran entirely in UWP, too, for a while. It was said to have been one of the drivers for deep UWP support in React native at the time. There were also the React Native-based Word, Excel, and PowerPoint "mini" versions that ran entirely in UWP. Those are said to have influenced more of the real codebases pushing towards React Native, but did not try to replace the original codebases in the same way that "Outlook (New)" today is overtaking "Outlook (Classic)".
There were a lot of strategy problems with UWP, but adoption was further along in some areas than it looked.
There are still some things that are still locked in the UWP world that I wish were not.
For example, Windows classic desktop apps still have no equivalent to the UWP app lifecycle. Your UWP app's processes can be suspended and resumed without you writing code to force the suspension and request when to be resumed later. Instead, you are expected to appropriately handle event notifications for suspend, resume, and the app entering and leaving background state.
This system-managed UWP app lifecycle makes life harder for UWP app authors, but I think the net win for battery life is much better for the user experience, which is why mobile apps operate the same way. Yet the docs for the Windows App SDK, which is supposed to bring the best of the UWP to desktop apps, explicitly say that WinAppSDK apps control their lifecycle just like other desktop apps, and the only power friendliness in the WinAppSDK API is voluntary (aka no one will use it). [1, 2]
I'll probably write more soon in response to other parts of the original link's comment thread. Overall, I feel like UWP is being unfairly maligned here, and that while its introduction was unforgivably arrogant, Steven Sinofsky is also right that it was daring and necessary to fix the mistakes and outdated decisions of 16-bit Windows and Win32.
Those are some good points, and I especially loved that lifecycle management in the era where I used a lot of Windows 8 apps. Even on a Desktop with apps filling up my screen still seeing some of them pinned to 0% CPU most of the time (while I'm multi-tasking) in Task Manager was a delightful magic. I also agree that was one of the best parts of the UWP sandbox and one of the biggest shames when Microsoft had to figure out how to allow sandbox breaks that they couldn't find a way to make the lifecycle and other smarts parts of the sandbox more opt-out by default rather than "opt back into the full sandbox". Of course needing to opt-out by default was one of the reasons developers hated the sandbox in the first place. It's a marketing challenge no matter how you slice it.
That relates to some of my criticism that maybe UWP could have used more .NET veterans because that was one of the problems with the CAS sandbox. For the most part the CAS sandbox was "opt-in" and yeah software developers through ego, hubris, and everything else will most often declare "my app/library is a special snowflake and needs access to everything!" So even if things opt-in to additional security controls like CAS, no one tests or builds for Production in a CAS sandbox so even things that claimed to support CAS threw runtime exceptions all over the place to the point no one could trust CAS to the point were CAS died for being practically useless overhead because no one both opted in and knew how to test it.
UWP had a lot of good ideas. It's insistence that it didn't have much to learn from .NET's mistakes was not one of them.
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?
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.
I thought we're not discussing whether we like one UI over another but whether an OS's UI was (internally) consistent. You may dislike KDE, but it uses it's design language all throughout the UI from window manager, the application launcher, the settings dialog, everywhere. Windows famously has three (or more?) styles of control panel UI. You may prefer that, and to each their own, but it is inconsistent, which was the topic of this thread.
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.
Problem is, both Firefox and Chrome look out of place on it when you use a non-standard color scheme. Custom keyboard shortcuts won't work on Chrome. When you change a theme from light to dark and vice versa, both browsers like to have text in their UI stuck on the wrong color.
I could use Konqueror, I guess, but its ad blocking plugin (and plugins overall) seems to never have progressed much since KDE 2.
Right, applications can break all sorts of UI consistency. But the question is: do the standard components that the vendor ships do it? I argue: KDE is consistent. I don't want my desktop UI to dictate how an app draws its UI (or games would be impossible).
Even games need it, missing input field features has plagued PC games for decades and can be crippling for input method users, Skyrim's console needs mods to support copy and paste. Custom mouse acceleration curves is the reason everyone disabled it, zero acceleration is the easiest way to make different games handle mouse input consistently.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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?
> 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!
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.
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.
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.
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.
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.
I think you're comparing hand-writing an HTML/CSS interface to the WYSIWYG form editor of Qt or Visual Studio? Because hand writing a GUI in Qt/QML/C++/.NET is not any easier than writing it in HTML. There are tons of boilerplate and special markup to learn. The magical editor just hides all the plumbing from you.
I'll grant you that the lack of good WYSIWYG designers for working on web/electron apps is appalling, it's like RAD peaked in 1998 with VB6 and it's been downhill ever since.
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...
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 was more despised for being a gaping security hole than anything else, as I recall - the things you could do with it were really neat demos, but even back then, I said "I am not loading a random website that can access local things every time I log in".
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.
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. "
> 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.
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.
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.
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.
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.
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.
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.
I think you should look at the graphic. It's riddled with inaccuracies and nearly-unreadable spelling mistakes and mangled typography. I think that's plenty of a good reason to flag it.
I think it really abuses the assumption of good faith and the default to generous interpretation, because it forces you to divorce the author from their own published work in order to view them seriously. I suspect most of the comments here are generously ignoring the included graphic. But in the most generous view possible, the author is fine with publishing wildly inaccurate statements.
I think this makes HackerNews much worse, and posts like these should only be flagged.
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.
In a more generous interpretation, there was silence, _then_ people said something. That makes sense.
But "That silence is the story." is still a pretty telling non-sequitr, and it doesn't seem like the kind that comes from sloppy editing.
The punchy "Thing. Thing. Thing." is used constantly. We see it constantly in this article:
> 852 pages. Win16 API in C.
> Message loops. Window procedures. GDI.
> One OS, one API, one language, one book.
But those are minor sins. But in the end of the article, Snover states that Microsoft pitched C++ in 2012. That's so incorrect! The contents of this blog post are at least partially falsified.
Plus, the thesis statement is nonsense:
> When a platform can’t answer “how should I build a UI?” in under ten seconds, it has failed its developers. Full stop.
"Full stop" is a pretty heavy thing to end a nonsense statement with. How an inanimate software platform can "answer" things is not implicitly obvious, either. Is it a human representative? Are they the docs? Is it through a good UI?
The post is about Petzold's / Reccold's "Programming Windows", but it is apparently 852 pages, so that certainly wasn't answered in under 10 seconds either.
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.
Yes, those are all different versions of the underlying widget frameworks. I don't understand your point. My current GUI is KDE Plasma 6.6. The only libraries I have installed are Qt 6 (which I am not sure why you didn't list). I have no need for version 5 or 4, or any other. The GUI is consistent.
When I last used Windows, on a fresh install, I saw a mixture of different frameworks used for core OS components from the same vendor.
When I last used OS X, it was pretty consistent but I hear complaints from friends that its no longer the case.
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...
The rules didn't have to be reinvented - web/mobile devs chose to ignore them.
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.
It is absurd that there is no standardized UI toolkit, or rather that the web browser _is_ the standard with is characteristic _lack_ of user interaction idioms.
The fact that there are multiple platforms for UIs* is a huge failure of the industry as a whole. Apple, Microsoft and Google could have had a sit down together at any point in the last 20+ years to push some kind of standard, but they decided not to in order to protect their gardens.
*: a standardized UI platform doesn't necessarily mean a standardized platform. Just standardization of UI-related APIs and drawing.
My guess 10 or so years ago was that Google would be the first to bake Material UI into browser with web components, and then any browser would essentially reuse that to extend out whatever style they wanted. It really seemed like the way the web (and Google was heading). Instead we got bad Material UI knock-offs in about 45 different UI frameworks.
I'm not convinced that it's possible to create a UI toolkit that works on both desktop and mobile without one compromising the other. It's a bit like trying to design a vehicle that can serve both as a 2-ton pickup truck and as a golf cart; the needs of the two are just too different.
Another reason is that in 2000 if you wanted pointless UI wank you had to implement it yourself from scratch. Today with bloated frameworks where the developers ran out of ideas 15-20 years ago and have filled the intervening time adding wank that no-one asked for and no-one needs, everything you build with it gets to include every brain fart someone had at 4am back in 2017 that they thought looked cool at the time.
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.
Isn't that windows only?
> basic rules that had been in place for ages. Things like: [...]
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".
IMO the ubiquitous Yes/No/Cancel is even worse. No and Cancel are too conceptually close. Doesn't help that these usually show up when you're about to lose all your unsaved changes.
We've got big screens now! use more words! Save changes/Discard changes/Don't quit.
"cancel" means cancel the last operation (e.g. "quit the program", "yes/no" is an action taken on the prompt.
I understand those prompts perfectly fine, but they are panic inducing for e.g. my mom who has about a 50% chance of clicking the wrong button and losing work.
- 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.
Some Microsoft managers started suppressing people who reported internal defects, instead of leveling their teams up
That sounds like Goodhart's Law in action.
Bad metrics. That's why Microsoft cleaned house of midlevel managers a couple years ago. But the culture remained in places.
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 ..
> 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.
No. I want things like keyboard shortcuts to reflect the platform norms of where the app is running (macOS in my case). A shared core is fine, but the UI framework must be native to be acceptable. Ghostty is a "gold standard" there.
This is why most web apps are lowest-common-denominator annoyances that I will not use.
Indeed, if the framework is sensible, keyboard shortcuts reflecting platform norms is entirely attainable in a manner that developers don't have to bother with it, much, if they don't want to.
There are plenty of examples of cross-platform UI's surviving the hotkey dance and attaining user satisfaction. There are of course poor examples too, but that's a reflection of care, not effort.
>i.e. dissuaded from using native, but rather bespoke, UI frameworks.
Based on my experience, I would be quite reluctant to rely on any non-native cross-platform desktop UI framework that is not web-based. These tend to be either less performant, look outdated or are bug-ridden.
What about Qt? It is the gold standard for cross-platform desktop UI frameworks.
It is (1) performant (C++-based), (2) does not look outdated, and (3) not bug-ridden.
Qt apps don't feel great on macOS, though it's by far the best for mac-ish UI. Dropbox was Qt for a long time and I'd argue it worked well for them. Its easy to fall into "uncanny valley".
On Linux, Qt apps feel a bit off in GNOME, though you can never satisfy everyone as its the wild west.
I think Qt also suffers from not really being anyone's favourite.
On the one hand, you have web developers who tend to not really appreciate the nuance of the desktop as a platform. They're not going to advocate for Qt, it's not CSS/HTML/JS.
On the other hand, you have native Mac developers who love Apple's toolkits (AppKit, maybe SwiftUI). They're not going to advocate for Qt either.
Lastly, you have native Windows developers who have been burned so many times they don't advocate for anything in life anymore.
> On Linux, Qt apps feel a bit off in GNOME, though you can never satisfy everyone as its the wild west.
It's much better than how GTK apps feel under Qt-based DEs - at least Qt tries to adapt to the DE style.
I think Qt is only missing well-written, feature-complete bindings for a major JS runtime, including support for hot reload.
Developing UIs without hot reloading is too painful.
I think what you're asking for has existed for a long, long time. QML.
QML is an entirely separate widget toolkit that really isn't a great fit for desktop programs - it's not much different from using a web-based toolkit.
QML doesn't have a way to define interfaces with JSX and doesn't integrate with the wider JS tooling. From my very limited experience, it still feels too close to the C++ world.
This isn't true, but I understand why you feel that way.
Qt had bindings to many languages, C++ is a choice, not a demand, if you'd like to use Qt.
> This isn't true, but I understand why you feel that way.
By all means, I'd be happy to be proven wrong. Last effort I saw on this direction was node-gui + React. I believe that project isn't being maintained. Being able to use something like Vite to build desktop programs would be a blessing.
In my experience:
- Qt Widgets worked fine, but looked like a piece of software made in 2013;
- QML looks stylish and is a very nice language, but had a lot of weird bugs.
Neither of these are issues I'd run with if I were to make a web app.
Widgets looks like whatever you want them to look like, if the feel like they're from the 2010s its because the implementer made that choice, not because of a limitation in qtwidgets.
As I understand the philosophy of Qt, it does not (for the most part) use native widgets. They seek to draw widgets that match native widgets on a pixel-by-pixel basis. You can also change the look-and-feel (similar to Java Swing widgets) by using what Qt calls "styles". Ref: https://doc.qt.io/qt-6/style-reference.html
Could be, but I am mostly speaking about the fact that making a web app looks stylish feels infinitely easier to me.
Qt uses css. Its no different than what you’re describing.
> - Qt Widgets worked fine, but looked like a piece of software made in 2013;
That's too bad, because I prefer software which looks like it was made in 1999.
Ah, the magic times when screen resolutions were large enough to display lots of information, in proper 4:3 aspect ratio, just before they got flattened and the industry started treating them as short view distance TVs.
That's your prerogative, but web-based UI's have their hard limits, and native cross-platform desktop UI's are no more/less problematic than the browser.
It seems you fumbled your starmenue click, the start menue will be right back, right after these messages.
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%.
>their telemetry showed that few users used them
I wonder if they ever stopped to think that power users are the ones that disable telemetry immediately upon install.
That's not remotely universal, but they did consider that. It's immaterial.
It's really not immaterial. Power users are also the ones that get anyone to install Firefox in the first place.
Considering Firefox market share trends all decisions at Mozilla should be by default considered textbook material for what not to do.
Sometimes this is a self-fulfilling prophecy. It is the novice users who, over time, become power users through repetitive usage. If there are no user efficiency gains to be had through experience in a UI, then it just prevents the emergence of power users. Users just have to wait until a product manager or designer somewhere notices their pain and create a new feature through 10x the effort it would have taken to simply maintain the lower level shortcuts (e.g. keyboard accelerators, simple step automations).
Was it the same 1% that was using each of the long-tail features? I suspect that by refusing to invest effort in at least some amount of niche features, we essentially alienate _everybody_
Browsers like Vivaldi that cater to power users are gaining in popularity. They are not trying to be the next Chrome, they are just out to serve their niche well.
Firefox has nothing to differentiate itself from Chrome at this point.
>Firefox has nothing
Not only that, but for a time, Firefox seemed to be copying everything Chrome did, maybe as a way to stop the exodus of users. But people who wanted Chrome-y things were already using it, and people who didn't might as well, because Firefox was becoming indistinguishable from it.
God I wish Mozilla would be made great again. It's tragic how mismanaged it is.
> It's tragic how mismanaged it is.
Is it mismanaged? Sure, they spend a fair amount on administration. Sure, they spend about 10% on Mozilla Foundation stuff. But they still spend ~2/3 of revenue on software development.
And they're somewhat stuck between a rock and a hard place.
If they try to evolve their current platform, power users bitch. If they don't evolve their current platform, they lose casual users to ad-promoted alternatives (Chrome and Edge).
And they don't really have the money to do a parallel ground-up rewrite.
The most interesting thing I could see on the horizon is building a user-owned browsing agent (in the AI sense), but then they'd get tarred and feathered for chasing AI.
Part of Mozilla's problem is that the browser is already pretty figured out. After tabs and speed and ad blocking, there weren't any killer features.
To a first degree, nearly everyone who installed Chrome did so because of Google putting "Runs best in Chrome" on every page they own and including it with every single possible download, including things like Java updates!
Almost nobody chose Chrome. Microsoft had to change how defaults were managed because Chrome kept stealing defaults without even a prompt.
People use "the internet", they don't give a fuck about browsers. Firefox only got as high a usage as it did because of an entire decade of no competition, as Internet Explorer 6 sat still and degraded.
Chrome was installed as malware for tens of millions of people. It used identical processes as similar malware. It's insane to me how far out of their way lots of "Tech" people go to rewrite that actual history. I guess it shouldn't be surprising since about a thousand people here probably helped make those installer bundling deals and wrote the default browser hijacking code.
It should be a crime what Google did with Chrome. They dropped Chrome onto unsuspecting users who never even noticed when malware did the exact same thing with a skinned Chromium a couple days later. Microsoft was taken to court for far less.
How was Mozilla supposed to compete with millions of free advertising Google gave itself and literal default hijacking?
Container tabs, independent proxy config (chrome only respects system-wide proxy), vertical tabs, and functional adblockers are the four big features for me.
Try installing Sidebery or a good adblocker on Chrome.
I use AdBlock on Chrome. It is excellent. Do you not like it?
Go to an adblock test page in Chrome and compare it to Firefox with uBlock Origin. Chrome can't block some ads, and some of the ads it can block leaves behind empty containers.
Personally, its not so much about customisation as it is consistency, quality, and attention to detail.
Being able to keyboard through menus as standard. Focus being deeply considered and always working as expected.
Compact UI elements -- in the 90s/00s we decided buttons should be about 22px tall. Then suddenly they doubled in size.
> 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).
> 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.
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.
>And at that point you also realize that are better OSes
Nothing beats Windows 11+WSL2; literally the best of both worlds.
Nonsense. Do you read and write your email using the command line? I use Mutt and Vim for that, and that’s not the command line. GUI with power-user support is just as efficient as Mutt and Vim. Did you use curl to read this thread and submit your comment? I use Firefox with Vimium C, which allows most web pages to be navigated and operated efficiently by keyboard.
Wait, mail clients other than mutt exist?
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.
> 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.
The issue is that everyone wants a full-featured remote with only "on, volume, and channel changing" buttons.
I'm planning on writing a desktop (I've wrote about some of my goals here before) precisely for this reason
This is why, for me, year of the Linux desktop was 2008. It's been atrocious since then.
[flagged]
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.
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.
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.
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."
Or better yet, Settings > Apps > Default apps > select a different browser
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.
I do not think the current computers can catch up with Electron. When it is just one or two simple app it is ok, but when everything is built with Electron (which is happening now) then it is not enough even with 32gb+ ram.
What have you heard about SwiftUI being bloated?
My lived experience. Maybe bloated isn’t the right word, but attention to performance just isn’t there. Try using any swift UI app on iPhone or Mac. Try resizing a swift UI app window on Mac.
Yeah, it's not bloated, there are just a lot of surprising and weird performance holes, especially on macOS. Even on iOS there's dumb things like, if your List cell's outer view isn't a specific type, List won't optimize for cell reuse, and it will start dequeuing cells for every item in the List eagerly. Wrap your actual cell type with a VStack or something and it will work properly, only dequeuing visible cells. It can be really nice to work with, but man, some of the implicit behavior, performance other otherwise, is shocking.
[flagged]
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.
My recollection of current events at the time was that you were already having a dogshit experience using computers for many common things in the XP era with underpowered video hardware and trying anything complex in a browser, or Flash things with a lot of assets, so it's less forcing escalating a baseline and more recognizing the realities of what people were already expecting in a "good" computer and building thing that could take advantage of that.
I would agree it should have degraded much more gracefully and more readily than it did, but I'm quite confident we hadn't hit the point of minimal returns on improvements in hardware that would be necessary for such an argument yet.
Hell, I probably wouldn't make that argument until large amounts of RAM and VRAM (or unified RAM) are ubiquitous, because so many workloads degrade so badly with too little of either.
Apple had been doing GPU-accelerated GUIs since the early NeXT days; it was certainly possible on hardware weaker than what Vista required.
Minor correction: Apple introduced GPU-accelerated GUI in 10.2 with the introduction of Quartz Extreme.
Display PostScript did not have GPU acceleration, as far as I know.
https://en.wikipedia.org/wiki/Quartz_Compositor?#Quartz_Extr...
Windows 3.1, with the aproppiated drivers and modern SVGA card, had accelerated 2d graphics. Accelerated GUIs don't even need GPU or 3d.
What does "GPU" mean here? Previous uses of the term seemed to imply "dedicated hardware for improving rendering performance" which the SVGA stuff would seem to fall squarely under.
The term GPU was first coined by Sony for the PlayStation with its 3D capabilities, and has been associated with 3D rendering since. In some products it stood for Geometry Processing Unit, again referring to 3D. Purely 2D graphics coprocessors generally don’t fall under what is considered a GPU.
It has been associated with 3D rendering, but given that things like the S3 86C911 are listed on the Wikipedia GPU page, saying "Accelerated GUIs don't need GPU" feels like attempting to win an argument by insisting on a term definition that is significantly divergent from standard vulgar usage [1], which doesn't provide any insight to the problem originally being discussed.
[1] Maybe I've just been blindly ignorant for 30 years, but as far as I could tell, 'GPU' seemed to emerge as a more Huffman-efficient encoding for the same thing we were calling a 'video card'
I don’t agree with what you state as the vulgar usage. “Graphics card” was the standard term a long time, even after they generally carried a (3D) GPU. Maybe up to around 2010 or so? There was no time when you had 2D-only graphics cards being called GPUs, and you didn’t consciously buy a discrete GPU if you weren’t interested in (3D) games or similar applications.
In the context of the discussion, the point is that you don’t need high-powered graphics hardware to achieve a fast GUI for most types of applications that WPF would be used for. WPF being slow was due to architectural or implementation choices.
That's the real takeaway - WPF should have degraded gracefully (read, full speed performance without the bling) but it didn't.
We used to call those things a "Video Card", which you put into your computer to get a video signal out.
Back in the day there was a card called an S3 Virge, which we affectionally called a 3D decelerator card, because of its lacklustre 3D performance.
Most people consider GPU to mean "3D accelerator" though technically it refers to any coprocessor that can do work "for" the main system at the same time.
GPU-accelerated GUI usually refers to using the texture mapping capabilities of a 3D accelerator for "2D" GUI work.
Calling that "the GPU acceleration" on Mac OS X was a bit overstating the things. It supported rotations, compositing, and some other bulk operations, but text and precise 2D graphics was rendered on the CPU.
It _still_ is not trivial to render high-quality 2D graphics on the GPU.
I mean Apple had a GPU-accelerated GUI in 1990, but probably not what we think of "GPU accelerated" these days
https://wiki.preterhuman.net/Apple_Macintosh_Display_Card_8-...
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).
emacs + bitmap font for me and I'm continually shocked when I have to use something else by how it is blurry and laggy.
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.
> 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.
The promise was that WPF would use hardware-accelerated libraries such as DirectWrite to put text on the screen even faster than GDI+ (using the CPU) could do. The reality turned out to be quite different: multiple layers of abstraction and just plain inefficient WPF code [1] meant that users needed powerful CPUs and GPUs just to get reasonable performance.
[1] https://faithlife.codes/blog/2019/06/improving-wpf-text-disp...
I’m knee deep in refactoring LibreOffice code around text rendering. I can assure you, it’s complex but it doesn’t require a GPU!
Hmm doesn't that sound like Apple's Tahoe/iOS 26? Effects upon effects upon more effects.
iOS 26 runs surprisingly smooth on my iPhone 12 Pro Max though.
Runs like crap on my daughter's 12 mini.
Actually what does "surprisingly smooth" mean? Better than you expected? Or actually smooth?
I had an Xperia for a while but kept my iPhone and then installed the iOS 26 beta on it. Expectation was that it would run but be pretty painful. Surprisingly, even the beta ran so fine that I sold the Xperia and switched back to iOS. And it's still my daily driver.
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.
2008 edition of “let’s rewrite it in react”.
2008 had its own version of React and it was called Adobe Air
Adobe Air was just Flash wearing an ill fitting business suit.
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.
That may be how JavaScript started, but unless your claim is that JavaScript hasn't changed at all in the thirty years or so since then, your argument is a complete non-sequitur.
Yeah, thank you. Also, JavaScript today means TypeScript—an arguably extremely capable type system actively developed by Microsoft—and several, modern runtimes with a big standard library and solid asynchronous primitives. There are a lot worse scripting languages out there.
Folks misunderstand the whole point just because I mention TypeScript. Sure it’s a capable and elegant language. Doesn’t change the fact that it’s a bloated monstrosity on the desktop.
Think about it: it transpiles to JavaScript. Even if it’s the most elegant language in the world doesn’t change the fact that it’s a world of bloat.
Stacks on stacks on stacks. And yet people are complaining about .Net? Come on. Lol
Transpilation and bloat are orthogonal. Javascript being bloated or not is also a relative: consider Python, which is much slower than js, and much more memory hungry.
To further argue your original point: chrome & electron are the only reason desktop is still around, both Microsoft and Apple tried their very hardest to build a walled garden of GUI frameworks, rejecting the very idea of compatibility, good design, and ease of use, until they were surpassed by the web, and particularly Google, showing that delivering functioning applications to a computer does not require gigantic widget libraries, outdated looks or complicated downloads & install processes, but is in fact nothing more than a bit of standardization and a couple MBs of text.
All this electron & web hate is so incredibly misplaced I don't even know where to begin. Have you tried making a cross platform mac/win native app? I have, its like being catapulted into the stone age, but you're asked to build a skyscraper.
Why would transpiling change anything? C++ was once transpiled into C. I appreciate that you personally think JavaScript is poorly designed (I mostly agree!) but that doesn't mean it's slow. V8 can do miracles nowadays.
Doesn’t matter how it changed if every desktop app ships its own browser.
Remember we’re talking about GUIs. Typescript is great for the browser but it should stay there.
Now, JavaScript can be okay for example: Qt Quick/QML it works quite well in the desktop. But that’s purpose-built scripting.
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..
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.
Sure, if we ignore the stuff and bugs they still have, the missing features in SwiftUI and performance regressions, or the iPhonisms brought to macOS with Catalyst.
The reboot of frameworks based in OpenGL with the Metal rewrite.
And many other things I am not bothering with since all those OS System N releases, A/UX UI framework, Teligent based documents,....
Come on, you think SwiftUI has more bugs than the ten different Microsoft frameworks?
There are just more people encountering them because the developers are concentrated on using one thing.
It’s not perfect, but a compared to Microsoft, calling Apple out for having bugs is a little rich isn't it?
I pose to you, if the Microsoft offerings are so compelling, why are the serious players using 3rd party wrappers like QT and Avalonia?
It’s because the first party offerings are not compelling. They’re a disaster dumpster fire. And buggy.
If Apple products are so compelling why are so many devs using Electron, React Native and Flutter on macOS, to the point it deserved being mentioned at WWDC 2025 State of the Nation Keynote?
My point was don't throw stones when having a big glass roof as well.
Apple isn't the perfection you make out to be, also has a rich history of failures, and only did not went bankrupt due to sheer luck of doing the right decision when there were not many remaining to take.
That's a different issue. Things like Electron are popular not because native development is buggy, but because most developers these days are web developers. They know Javascript. They've never written anything in C/C++ or even the slightly friendlier Swift, Rust, or Go. Electron lets people who only know the Web make desktop apps.
Nope, it is the same issue now being worded around to sell the Apple is shiny story above.
> Apple is shiny story
Is a fantasy you invented to argue against.
Microsoft’s 1st party offerings are an embarrassment.
Apples first party offering isnt amazing either; it’s just “ok”; but its not a total embarrassment.
> If Apple products are so compelling why are so many devs using Electron, React Native and Flutter on macOS
That is not how the decision making for cross-platform works. You choose those alternatives knowing that they are crap in many respects, yet accept the trade offs because you want to save money on dev hours.
The whole point was the greatness of Apple platform.
That’s not the point being argued either, nor it being perfect. It’s just about Apple’s UI frameworks being more coherent and consistent across all their own platforms, unlike Microsoft. Even Android developers who’ve done a bit of work on iOS easily agree that Apple’s SDKs are far better designed and behave more predictably than Google’s.
They use React Native and Flutter because they want to target more than just MacOS/iOS
Meaning they don't worship Apple UIs as the ultimate design?
It's about the tradeoff.
Option 1: spend double the effort, embrace Apple's UI
Option 2: do it once, ship faster, make more money.
Nobody in this thread is claiming Apple is perfect, just ahead of MS in UI consistency and _less_ buggy
"Ahead" with yes but attitude.
None of the UI frameworks is perfect. Neither the ones from Microsoft, nor the ones from Apple, nor Qt, nor GTK (lol...), nor the web-based ones.
I'm just saying that in my personal opinion and experience, the ones from Apple have the best yay-to-wtf ratio. Your mileage may vary.
The evergreen question of "how do you go back and/or close an app on IOS?"
This one caught me completely off guard when opening YouTube the first time on an iPad: Accidentally clicked on a wrong button and got stuck in a "please subscribe to premium" modal. No amount of swiping or tapping outside the popup would help, only thing left was killing the entire app.
This experience put a major dent in my perception of the "Apple has the most intuitive UI" narrative.
The YouTube app has non-standard and nonsensical UX on every platform. It's Google's fault, nothing to do with Apple.
Case in point: The YouTube app for Apple TV. Everything (pausing, playing, changing subtitles) has been done opposite to the standard player found in every other app. You cannot use the main button to pause and resume, for example. Recently they broke swiping. Normally, you swipe the remote to navigate between UI elements such as squares in a grid or in lists with a light touch. It's very fluid, like a touch screen. But the YT app has added severe "inertia" to touch gestures, and you now have to "fling" your finger on the remote trackpad to navigate. Everything feels syrupy and stuck.
YouTube and Amazon's Prime TV app are the two worst apps I've ever used on Apple TV. I believe they both use some non-native UI toolkit that doesn't respect native OS conventions and doesn't even try to. Pretty incredible given the size and budgets of these companies.
The YouTube app does the exact same thing on Android. I ran into this just yesterday on my gf's phone, as I'd just added her to my family plan, tried to verify the settings on her phone, and it trapped me on an upsell screen for YT Premium that I had to kill the app to get out of.
How is bad UX in the YouTube app Apple's fault? You can mess up Android's back button as well.
Because Apple does not enforce uniformity
If Ah, yes, problems with the UI on the OS which for 99% consists of modals is not the OS vendor problem, noted.
Maybe just the circles I run in but these are not evergreen questions in my experience. I don't even know what "go back" is supposed to mean here, or for that matter what it would mean in a Windows application. Is there a system level "go back" in WinAmp/Excel/SimCity/Photoshop I've never seen before?
I was referring to IOS, not MACOS
Androids do have universal back button at the bottom on the phone or the same swipe gesture if you want but iphones do not.
Sometimes swipe (the direction and position is a guessing game), sometimes and x (right or left ) and the behavior is inconsistent too (back or close)
There are some guidelines but more often than not seems like every app has it's own method and you need to get used to it
In iOS, task manager and closure can't be overridden. You swipe right to return to previous application. You can swipe left for a couple of seconds if you didn't intend to do that.
You swipe up and remove the application from the stack, all processes of the application is killed.
Background processing has strict limits, and you need permissions to run longer than that, and for some use cases, there are no recourse. OS swaps you out or freezes the app.
If you want an app to work in the background, don't kill it, period. Push notifications are handled by the OS and is not hindered by this.
What about going "back" INSIDE an application?
Think for example reddit, you open a thread, how do you go back?
You open the "reply window, now ho you ho back? Maybe close it directly?
I Android this is all handled by the same function and is often ranked as the most frustrating design choice in IOS
I'm not using Reddit in any capacity since they have started giving their content for LLM training, so I can't help you with that, but looking at 4-5 third party applications right now, they all have a left arrow at top left to go back.
They all are very different applications and have very different designs, yet the arrow is there.
To be honest, I baffled at your question for a second or so, because I never thought about that, yet the method is so universal that I was not thinking about it at all.
There is a common way to go back (swipe from the left edge of the screen). Some apps just don't integrate well and ignore the platform patterns.
I believe swiping from left to right is common for both Android and iOS.
Android has both a swipe gesture or a widget that simulates buttons that used to be at the bottom of the screen
...and iOS has both an arrow at the top left and a swipe gesture. I can't see how they are that different.
I feel that some people are just too old to get used to the swipe based ui. I mean friends of mine who just keep buying the only phones with (screen based) back and home buttons.
It's not just that you need to get used to gestures, it's that they are not discoverable at all, and that they can be awkward to perform with mobility issues, old hands, short fingers, etc. It's easy to make the wrong gesture, eg. the phone detects a swipe down instead of left to right, more so if you are holding it in one hand, so it's finicky and frustrating to have to rely on it as the only way of doing a common action. Why is it so wrong to have a simple navigation bar, it doesn't take up any more space than the hideous notch at the top?
I'm in that group.
It's not "getting used to", I feel like that gesture is less practical. It involves or using the "circle" to assist on how to use the gesture (creating a black void on the screen that you need to plan your use of the phone around) or having the swipe that 1) is not as reliable in my opinion and 2) can be triggered accidentally
For me is like claiming that touch screens on cars are the future and people are too old to get used to it.
Maybe saying "too old" is disrespectful indeed, what I meant was more that my kids grow up with swiping everywhere but we grew up with (hardware, then touchscreen) buttons and the older we get the harder it is to get used to new use paradigms.
Swipes are of course nice because they allow for the same interactions without taking any screen real-estate. And I have to say it quite consistent across the iOS apps I use.
I could get used to touch gestures if they were more consistent and tolerant enough for wrong inputs. It may work in one app but not another. One app expects me to swipe from left to right to go back, another wants me to swipe from top to bottom for the same thing. It may mark an email as unread if I start the swipe a pixel too far away from the screen edge. On Android swipe gestures may vary even on different phones from the same brand. In iOS, tapping the top edge of the screen means scroll to the top. Except in the Photo app, where it means "scroll to the top of the current section, or almost the top, or do nothing and make the user guess if they just tapped the wrong way".
Meanwhile when there's an X button or arrow to the left I always know what it's going to do aside from one or two overly creative Android apps.
I feel that some people are just forgetting what the reason it's easy for them is because they learned that "swipe based UI" ages ago.
When I get handed iPhone I have no clue on how to even open an additional tab in Safari and any finger gestures do not do the things what I expect nor there is a lick of indication on how to do something. It's all just a memorized magical incantations at this point. But hey you are familiar with them so it's easy to bash on everyone who is not in yours eco-system.
It's not just mental, as you age you lose moisture in your skin and with that accuracy with touch devices.
Is that what's going on? So many touch gestures seem to rely on landing in the right 2mm diameter area, but the minimum reliable resolution for touch seems to be a 4mm diameter circle. It's even worse for my father, even though cognitively, he would have no trouble understanding the hypothetical requirement. It's also noticeably worse during the depths of winter.
Hmm, would explain that frustrated pokey interaction I see elder people often throw at touchscreens... you know, chin up, peering down through their reading glasses, going for a 4th, 5th try at something...
Android has an option to enable these buttons on a toolbar at the bottom, I always turn it on.
Why change what works fine? Maybe that's the definition of being too old, can't be bothered to change to new things.
You swipe backward. Been that way for twenty years.
It's still easier than Windows CE though.
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.
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.
Does it need it?
Good point. Akin to Qt Widgets - it doesn't really need it on desktop. HW acceleration is crucial on mobile, but WinForms doesn't have a story there.
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.
>WinForms is a layer built on top of raw Win32. So it's not portable.
Neither are SwiftUI and AppKity.
True, but: Microsoft haven't made a better UI framework that's portable to Windows yet. Everything after WPF has near zero adoption, including (critically important!) by Microsoft itself.
Mono used to have libwine embedded. You know, libwine exists as a library running and compiling Win32 natively under Unix. Instead of PE binaries you would run ELF Linux ones, but with nearly the same outcome.
Every time I tried following alone with the winelib/winemaker documentation, I always ended up with an ELF that had to be invoked using "wine" to run. Nothing that could self-load any of the wine dependencies.
Mono supported WinForms. But IDK how did they integrate it with the CIL.
But for sure they used WineLib.
> 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.
The size and losition of the traffic lights control is not dependent of the os the app runs on but on the os the app was compiled on. So things are not updated across the board
This is incorrect.
It’s still dependent on the OS it runs on AND the SDK it compiles against (not the OS it was was compiled on).
But that is legacy bridging behaviour, and is not compiled into the app. Apple can and do change those with time.
For example apps that compile against macOS 15 are not opted into Liquid Glass when run on macOS 26 but will be once on macOS 27 according to their transition docs.
That doesn’t really negate the OPs point.
I found this out when I tried running an old app I compiled on MacOS several years ago, it still has the old title bar gradient and traffic light.
That's a bad thing. It breaks apps. Apple has decided to stop supporting apps that aren't continually updated. Microsoft hasn't.
I don’t think Microsoft’s approach to perpetually support old apps is unequivocally a good thing. It seems to be getting them into a deeper and deeper mess over time.
As a consumer I prefer Apples approach. If I were an industrial customer relying on old software to operate my machines i would prefer Microsoft’s approach.
Insightful comment
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
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)
All the various windows UI frameworks are stable, but not supported and not receiving new updates.
That's the problem.
And what makes matters worse is because of all the shifts, the documentation throughout MS is in just varying states of outdated. For example, this document which recommends using UWP [1] to handle high dpi problems. But of course, UWP (which was the right way to do gui in Win 10) is now defunct for win ui.
[1] https://learn.microsoft.com/en-us/windows/win32/hidpi/high-d...
WPF is also stable. Microsoft's UI strategy is similar to keeping all of Motif, GTK2, Qt5 alive while engineering new stuff into Qt6 without deprecating anything.
Btw Linux UI is not by any measure stable. It is the furthest thing from stable.
I'm still using Win32 (via WTL) to write a developer focused application, but I know that someday I will need to switch to Qt, dear ImGui, or develop my own UI abstraction layer.
The biggest disappointment has been that all new OS features require a new runtime and are not accessible from just pure Win32 any more. Heck the pipeline for developing UWP/WinUI3 apps requires extra steps to register and install the application just to run it inside a debugger.
GTK 2, GTK 3, or GTK 4?
Various versions of GTK which introduced breaks but didn't really change the core philosophy of how you build a GTK app. IMO, this is the preferable way to evolve an ecosystem.
The problem microsoft has is instead of making "Win32, but with these extentions or these APIs removed", heck even as a separate "framework". What they did instead was "You know what's hot right now? XML. So let's make an XML based UI framework. Actually, it's javascript and css, so let's do that. Actually, people really like electron so let's do that."
That is to say, it is possible and I dare say easy to migrate an application from GTK 3 to GTK 4. It's basically impossible to migrate a WPF app to UWP. You have to rewrite the whole thing.
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
Yeah, especially funny since they had the early lead with their iPaq PDAs and Windows CE. Which they completely squandered by ignoring them.
Then they acquired Nokia that already had an almost-ready ecosystem of apps, with good snappy UI. And then spent two years building a (shitty) framework on top of the long-neglected Windows CE kernel. Which was known from the start to be a stopgap solution before they port the full WinNT kernel.
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
Not really. They are merging it with Android. Or in other words, they're making Android into a full-blown desktop OS.
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?
Safari isn't that bad for most applications.
Sure it is a hassle to get notifications working, but my take on that for years as a desktop user was "I need another source of spam about as much as I need to get raped". For years I had bottom of the line Android Tracfones and wondered "how is it people get so excited about apps?" because they just didn't work but once I got an iPhone I started to appreciate that the McDonald's app would send me a notification when my food was ready. Recently it was pointed out to me that the application behind these cards
https://mastodon.social/@UP8/116086491667959840
really would benefit from notifications ("your photos are ready!") and I am looking at the hurdles I can jump through and it looks possible but weird. Like why would I want people to install my app on the homescreen where it will get lost on page after page of twisty little app icons that all look alike?
Then there is that PWA boondoggle, there is another app in that system that I can use to register those cards and it is a clear case where I might want to do it outside of cell coverage (say I was in the woods) save a form submission and upload when I get back in range.
What can I say? That service worker system is insane, something like Kubernetes that only Google could subject us to. I mean, Google could have worked out the math for synchronizing a local database to a remote database, by then the Lotus Notes patents were mostly expired, we could have gotten something good. Or Google could have added an API to control the behavior of the browser cache. Instead we got something half baked and barely reliable and then Apple went out and made something a little bit worse. Had it been a good standard to begin with the outcome could have been entirely different.
still works everywhere? the snark doesnt get you firther than that
Works everywhere on modern hardware only.
Every time I open a browser on my aging Linux computer (which is running the latest Linux updates), I'm reminded of this...
Majority of software doesn’t need to care about that.
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.
The inconvenient truth here is also that following the system theme is an anti-feature for most apps. On the desktop, you want your app window to be recognizable at a glance, meaning the primary color should be the brand color, etc.
I currently have open Chrome, Spotify, Discord, Aseprite, and Zed. All of them look completely different, and that's actively helpful for me, the user.
It's nice to follow the system's light/dark setting, and obviously the behavior of basic UI controls should be unsurprising, but beyond that there's no point in "consistency".
This. So often features to use system colors can cause apps to be unreadable or just look like crap. The first time I get a bug report that people can't read something I will lock the colors the down, I just don't have time for that.
Who says the system theme is well designed at all? Back in the 1980s you could count on most text color combinations on a Commodore 64 or an IBM 3279 or a PC with a CGA working.
Today it is absolutely normal to type
on a Linux machine out of the box and if you are running X or Wayland some of the file names are dark blue on a black background and completely un-readable. To be fair, if you are logging into a Linux machine on Windows with ssh on CMD.EXE or most terminal software you get similarly poorly chosen colors. (To be fair, MacOS does do better!)As a web developer it pisses me off because I am expected to follow
https://www.w3.org/WAI/standards-guidelines/wcag/
and regularly my management gets legalistic looking documents from customers complaining that we only have 6.5:1 contrast on something and you know what I do... I fix it. I wouldn't send anything to my tester that was unreadable and if I did I'd expect her to put in a ticket and I would... fix it. When MUI computes the coordinates wrong and something draws 20px right of where it should be... I fix it.
Whenever I've put similar tickets to the various parts of the Linux desktop mafia they close it as "won't fix" and often give me a helping of verbal abuse. Even Microsoft occasionally fixes something (even if half a decade late) and their people are polite.
yea there's so many ways through this now. golang and wails is great, rust and tauri is great. both seem to not feel like the slug that is electron because they just use whatever os native web view your os has.
for the dedicated more native stuff dioxus is kinda cool if you don't want a web stack in the mix.
i'm enjoying golang and wails though paired with whatever front end i want, all apps i've made perform execellent on windows. bottom line = yeah i can't really think of a scenario where i personally would ever write an app for windows specifically.
i, like you, used to get hung up on native vs web framework. i'd encourage you to give it a go, possible you cede that mayhaps the native thing isn't as important as you thought.
The DOM is very ill-suited for most UI. Too complex and lots of missing features. It’s a whole bag of unneeded code and the resulting UI doesn’t fit anywhere.
> The DOM is very ill-suited for most UI. Too complex and lots of missing features
Can you expand on this, because I'm not seeing it myself. The DOM, html+css is very flexible. It easily encompasses most UI. Most UI is some kind of data display, so lists, trees, tables, forms.
The need for JS might be what you're complaining about. I think we might be stuck with it as a UI control language forever.
The DOM(and CSS) is primarily built for documents and forms, even with the latest addition like Flexbox or Grid layouts. It is closer to typesetting tools like troff, latex, texinfo than any UI engines you can think of. And some that are not needed, like the difference between <i>, <a>, <span>, <strong>,...
Also with most GUI frameworks, there's some difference between widgets like label, button, menu, checkbox,... and containers that does layout management. And there are not a lot of elements in both sets. This is the reason why React Native has a very sparse components library. With simpler implementation, you have a simpler rendering path, and the developer have less elements to deal with.
Also some have ready-made implementation of really useful widgets, like tree, grids, tables, lists, and other dynamic things. You can find libraries for those on the web, but the web implementation of scrollable container is janky.
The GUI system for the NeXT was based on the Display PostScript system which in turn was based for the PostScript system designed for rendering to printers. Quartz in MacOS X is a further evolution of that.
Inside HTML 5 you can find facilities for rendering documents and you can find facilities for rendering applications, including those forms. There is not a clear line between one and the other.
PostScript was for rendering graphics to a printer with a good emphasis on texts. Most of HTML is about marking up and styling interactive documents. There’s no clear line between the two, but an API for applications UI has different goals than one for document typesetting (even interactive one).
HTML have a lot of tools for devex, but if you’re going for a good codebase and simple implementation for a desktop application, QT is way easier.
I don't know about "most UI" but it's sure as shit ill-suited for CAD (what I work on).
In which case you get canvas, WebXR, etc.
Why don't we have more great UI toolkits for the canvas?
Because many of those features aren't Web, rather Chrome OS Application Platform, but apparently folks forgot everything about IE history lesson.
> 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.
I know one of the GTK developers who dropped out of my research group in the 1990s who's been in charge of triaging tickets and he's the kind of guy who doesn't care if there is just 1.05:1 contrast between text and background and will refuse a one-line patch to make menus render right in rootless X windows because he wants to punish you for doing things in a way he thinks is wrong.
And he probably wonders why it is never "the year of the Linux desktop" but hey it is OK because Red Hat Linux is something enterprises subject their users to and if it had the slightest bit of flair customers would complain.
So when I hear GTK I think Nein Danke!
In general Linux has the kind of fanbois problem that MacOS had maybe 10 years ago. There are so many things that still "just don't work" after years and they never get fixed because you can live without them. For instance I can tell you how to install some package like
and that's all! I can make 10 pages of screenshots to tell you to click and click and click and click and click to install "mypackage" with the GUI [1] and you may wind up looking at a spinner for 10 minutes or longer (eventually you give up) and you might wind up corrupting your package database and not being able to install or update anything until you look up how to rebuild it. The Linux desktop is stuck with having done the 20% of the work that gets it 80% done and never does the rest of the work because you can use the command line anyway.[1] and you still might misunderstand it and need intensive tech support
What’s an example of a well made GTK or QT app in your opinion? And what would be the steel man Web app to compare that to?
Telegram Desktop (Qt)
We might contrast that with Slack, yes?
This thread comes to mind: https://www.0xsid.com/blog/wont-download-your-app With Slack that’s trivial, Telegram impossible.
Except Telegram Desktop is opensource and they also have full-functional Web version.
But tdesktop is really well-made Qt piece of software, snappy, feature-rich and multi-platform.
Interesting, at first pass I’d say the source availability has little to do with the topic at hand. But on second thought it might be rather significant. No company would finance making 2x identical cross platform apps, but if you have a pool of OS folks who are free to contribute at their leisure, the calculus changes a bit.
But isn't the whole point of linked article is that author doesn't like regular apps because it lacks control over UI and functionality compared to Web apps?
Being open-source is kinda even better in that regard.
A lot of grandeur but zero substance. Aside from performance, what would being written in GTL/Qt bring to VSCode or Obsidian?
[dead]
[dead]
>Your post is touching on a key question: why write a Windows-specific app?
Why write an anything-specific app?
What happens when the user doesn't have internet access, or only has very slow internet? What if they're on a metered connection?
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!
Features. Speed. Do your web apps only work in Chrome by the way?
I am a Firefox-first developer, almost everything I write works in Firefox/Chrome/Safari without a lot of drama.
I have one application at work that loads a table with 40,000 rows into a data grid that works really well on Chrome and lags on Firefox, that's the one case where the performance difference matters.
This year I've been interested in biosignals applications that read data with the Web Bluetooth API and Web Serial API which are ordinarily Chrome-only. I was about to get one of my junk Android tablets out of mothballs when I found there is Bluefy for iOS which supports the Bluetooth API so I have no problem going to labs where they have a really klunky HRV system based on a PC and show them something sleek on my iPad and in 20 minutes i can demonstrate to you, with your own physiology, everything you actually need to know out of a big review paper on HRV.
[flagged]
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.
One could (and I would) argue that they achieved that despite their web-tech-based UIs, not because of. At least those of us who were around for the days when most apps were still native, do notice and get bothered by the input lag, for instance.
Slack is, in fact, one of the worst offenders. It is so incredibly sluggish. And it doesn't need to be, when I compare it to the speed (and memory consumption) of Pidgin with the Slack plugin.
Async comm in web apps often keeps them responsive when the native app experience is: spinner... spinner... spinner... spinner... lock up the window and you can't move it... spinner... spinner... spinner... "should i reboot the whole machine first thing or should i try killing the app with task manager and starting again?"
Their killer feature, being able to share a link with anyone at the company and instantly collaborate (live!), is made far easier on the web platform vs native. “The input lag” frankly does not matter in the big picture, imo.
> As is VS Code.
That is, uh, controversial.
Along both "alleged replacement" and "alleged superiority" axes.
[dead]
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.
This makes sense, because even in the best times Windows was not the biggest money maker for Microsoft, it was Office. So MS was never fully behind Windows, it was only the means to an end, which was selling the most software for enterprises.
Ironically, Office was the original poster child for Microsoft reinventing it's own widget toolkits, even back when Microsoft had a coherent visual design and developer story.
How do you reconcile this with their history of bending over backwards to achieve backwards compatibility for third parties?
Because their strategy for getting their applications in front of everyone has always been to get Windows in front of everyone, and that meant having to support third party applications that they chose not to try to incorporate into their own apps, but which got enough usage that not supporting them would mean losing those Windows desktops, and thus losing those users of the MS applications that were on every Windows desktop.
It's quite possible that this attributes too much intentional strategy to MS, and also treats them as a single entity with a single strategy more than they deserve. The MS internal teams that were bending over backwards to maintain backwards compatibility were not the same as the teams that were churning out new APIs, building Azure, etc., and quite likely had very different incentives.
Microsoft was a language company at the start - they had a huge share in 8-bit computers and their BASIC made into the ROMs of almost every computer sold in the 70s and 80s. Then they branched out to applications, with little success (I remember Multiplan on CP/M, DOS, and Mac). When they started selling PC-DOS and MS-DOS they had no applications play to speak of. Office only came much later, and the apps that appeared for Mac, Word and Excel, were ported to Windows starting on Windows 2. Word for DOS struggled in the market and never reached a significant share.
> Office only came much later
In the sense of being marketed as a single integrated package, yes, I agree. I was using the term loosely to refer to the apps themselves (Word & Excel were the first two, as you note, the others came after).
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.
> "put a computer in every home and every office"
That was such an amazing mission statement. It was a real measurable goal, and progress towards it was quantifiable. And Microsoft actually did it! That mission statement drove actual strategies (lower costs, don't complete with Apple on the high end, force OEMs to compete against each other on price, etc) that resulted in its ultimate fulfillment.
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.
He had a strategy and it worked very well. But every strategy must be updated. It's basic BCG matrix stuff every MBA graduate knows by heart: sooner or later your star product becomes a cash cow and then a dog. To keep your company growing, you need to identify your next potential stars among question marks, boost them with cash from the cash cows, put competent managers in charge and remove those who get in the way.
Gates did this with Windows, Office, XBox among other things. Ballmer failed to do this this with Windows Phone. Nadella did it with Azure, but he needs to do it once again with AI. You can see that he's pushing hard with Copilots everywhere, what's missing is a manager that has a coherent vision of what AI at MS should look like. ScottGu is in charge of both Azure and AI at MS, but I don't know if he can deliver.
I agree with most of that. To be charitable to Nadella, at the time he first came into the role, Microsoft needed someone yelling "Cloud! Cloud! Cloud!" because the company was certainly behind folks like AWS. But for a long time he basically stopped there. Office migrated to the cloud and they pushed out Azure. Then he went on the AI rant and they decided that putting AI into everything, whether customers wanted it or not, was "the next thing." But now we're learning that Azure is a steaming pile of crap with customers leaving, and this article about GUI strategy shows they don't have an application development strategy. Everybody is fed up with Windows. Everybody is fed up with all the numerous "CoPilots." You actually have regular people investigating moving off Windows to Linux desktops. The one thing that Microsoft did exceptionally well through the 1990s and early 2000s was keep enterprises and app developers moving in the same direction. They bent over backwards to keep old Windows 3.1 applications running even on Win32 systems. That all ensured that nobody questioned whether they would work with Microsoft. They were the default and they commanded huge market power because of it. But that's all changed, and they have nothing to replace it. With everybody starting to ask questions that Nadella doesn't have answers for, it's going in a bad direction. Nadella needs to call his EVPs to account and force them to make some hard decisions about what lives or dies and then pressure test the resulting strategy with his customers, both old customers and potential customers. Surely, cloud and AI are a part of that future strategy, but he needs to figure out the rest of it.
Nadella took the reins in 2014 and the stock has 10x’d since then. In the same timeframe, the sp500 has 2.5x’d. Sounds pretty successful to me?
In theory, the market should be pricing in based on future potential. As it has become increasingly clear this past decade, the market is not rational.
In a bubble, everyone looks like they’re doing well. Don’t confuse that with an actual strategy.
But I compared it to sp500. Even QQQ only 6x’d in that timeframe.
Which bubble are you talking about? Even if you remove everything after January 1 2020, it’s still up 4x since nadella took over. And that follows a decade of stagnation under Balmer.
What numbers do you know of that show that Microsoft hasn’t been successful since nadella took charge?
Complain all you want about the products, but the stock under nadella has been a success.
Stock price going up is not the success criterion for a business. Making money is. And Microsoft's decisions are undermining their ability to make money in the future, which makes them bad decisions even if the stock price has gone up or if they make more money in the short term.
> Stock price going up is not the success criterion for a business. Making money is.
Microsoft’s net income is up roughly 5.4x from ~$22B in 2014 to $119B today. Profit margin also expanded, from ~25% net margins in 2014 to over 36% today.
If the market agreed, the stock wouldn’t go up.
Sure, but how much of that had to do with the design and implementation of Windows? You know, the OS that runs half of the modern economy. Microsoft is just milking it without a coherent vision.
Maybe financially MS is successful but at the cost of flagship product becoming adware and people fleeing slowly away
Cloud was taking off at the same time. Anybody in his spot would have been successful.
If your only metric is stock price, yes. That’s the value proposition of enshittification.
Cloud is now massively larger than any other part of Microsoft. It's why he became the CEO in the first place.
He maybe never had a strategy for Windows but he wasn't hired to have a strategy for Windows.
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.
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?
Most probably it was on purpose. MS is famous for the infighting of internal groups and how the management doesn't know how to control their divisions.
At one point, I worked on an app that periodically appeared in the top 10 of Windows Store sales.
Its income? Around $500 a month.
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.
This was sorted out in Windows 10 with the unification of WinRT programming models under UWP.
Nope, it wasn't solved in UWP days, neither it's solved today.
To satisfy my interest, I've tried creating WinUI app (aka UWP/WinRT) in Visual Studio 2026. And this is what I've got on the first app launch after compilation:
"This device needs to be set up correctly to develop this type of app for Windows. If you don't, then you can't install and test your app before you submit it to Windows Store"
I don't want to install/submit, I just want to be able to run my fricking .exe. Period.
So why are you calling this issue solved? To me, it's still right there in the plain sight - the same voodoo dances and delusional expectations of subordination to Windows Store.
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.
Yes, I agree, it's not apples-to-apples... but we're talking orders of magnitude in CPU, RAM, and "GPU" power.
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.
For all the grief they are getting GTK4/Adwaita/Gnome is doing a lot for performance and consistency of experience.
My GNOME desktop is more coherent than my Mac one at this point
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.
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...
As far as I remember, WinForms is just a thin wrapper around Win32 with a message loop, i.e. not all that different.
At the same time VB still works and runs, so they don't always rug pull.
They might have forgotten to pull that rug.
They did pull that rug, twice, in two different directions.
1) VB7 (VB.NET) entirely split the VB developer community.
2) VB6 IDE has not worked well and is entirely unsupported in every Windows after XP. It's generally recommend to build VB6 apps in an XP VM and XP being out of security support it's now a huge "Use at your own risk" and "Do your best to isolate the VM from ever having an internet connection". (Not to mention that installers like Install Shield that still understand VB6' super messy version of COM are generally also out of support and security support.)
It was alleged that Microsoft almost dropped the runtime components for VB6 in Windows 11. It starts to feel like only a matter of time before they do.
Definitely not, since it actually takes quite a lot of red tape to ship something as ancient as MSVBVM60.DLL in Windows 30 years later, and guarantee that it is still working.
It's just that it's a piece of tech from back when Microsoft corporate dominance on the desktop was at its peak, and many large companies bought into the then-current tech stack, including VB6. So now Microsoft is stuck maintaining it because those are the customers that bring consistent revenue.
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).
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.
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.
They thought after V8 the performance was going keep improving and reach native speeds, they didn’t understand that the major performance wins were all upfront and it would hit a wall.
> 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.
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.
It's that Nadella doesn't really care about Windows, even though the kernel is the root of Azure. In addition, all the newer gui frameworks abandoned RAD interface. That is what made and still does make Winforms and WPF popular.
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.
The UI part is exactly what I meant. WinForms was a godsend for professional developers making line-of-business apps, because previously if you used first-party dev tooling, you either had to deal with the considerable limitations of Visual Basic, or you had to deal with MFC that was low-level enough that all the things that were tedious about Win32 remained tedious. In comparison, Borland had Delphi, and there was a good reason why it was so popular back in 90s and early 00s, and why Microsoft ultimately acqui-hired its main designer specifically to work on .NET (and it very much shows in the design of both C#, which owes as much to Component Pascal as to Java, and of WinForms, which is so similar to VCL).
With WinForms, we actually got something that was convenient without shackling you. And the whole cross-language story was great, too, especially around .NET 2.0 - with C++/CLI you could very easily wrap any random native code C or C++ library for consumption from .NET, with end-to-end integration in the build system, IDE etc.
Eh, WinForms did a lot to make Win32 UI accessible and usable -- especially layout and easy customization -- but I have to differ on the cross-language story. It was great, IF you were making primarily a C# program that happened to use some C/C++ components.
From the native code side, it was not so great. The .NET 2.0 CLR had very poor support for hosting from the native side and really wanted you to make a program that was .NET first, it didn't work well if you wanted something like primarily a C++ program that hosted a C# UI in the same process. Reverse P/Invoke via native exports wasn't exposed, so creating DLLs for consumption by non-.NET programs was difficult. Mixed mode debugging was and still is painful, with the debugger being glacially slow at some operations like OutputDebugString() processing and blocking some native features like data breakpoints, and the CLR eating access violation exceptions from native code so they couldn't be debugged properly. Build-mode wise, we had to ban C++/CLI assemblies depending on C# assemblies because the C# project system didn't handle incremental builds properly and forced the dependent C++ assembly to rebuild all the time.
These issues still largely exist and are an issue with WPF. It's a great UI framework, but it's unusable unless your front end is primarily a C# program.
(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]
> 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.
At the risk of getting my Microsoft history wrong, I'm fairly sure that Steven Sinofsky wasn't working on Windows or even MFC (i.e. what he did as one of you guys) in .NET's early days of 1999-2003. He was leading Office at that time. Office of that era was transitioning from the Windows XP look that still persists in Windows Forms to the early Ribbon, and was then (as now?) using very custom GUI code that didn't correspond to any specific higher-level Windows app framework.
Mac OS Office apps had just separated their codebase again from Windows apps after being unified in the mid-90s to get to feature parity (which annoyed Mac users who felt they now had non-native-feeling apps that were slow and bloated), and the "Office framework" was still quite distinct from any single-platform Windows app as a result of that.
So if Sinofsky did not understand why people went from USER/GDI to WinForms, that may just have been the fact that nobody working for him had felt the need to make that transition.
> What actually happened [re Windows RT, but I think the point applies to UWP in general] 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.
The fact that UWP XAML was its own new thing and not a extension of an existing Microsoft GUI app framework like WPF was not necessarily a "we hate managed code" thing, or even a "we hate those guys who invented managed code and want to screw them because we're Windows" thing. After all, .NET managed code had equal access to UWP through the .NET WinRT projection!
And to me at least (I didn't work on UI-facing stuff in Win8), it was absolutely conceivable that UWP could have just delivered Windows Phone 7 Silverlight's version of XAML to native code apps, with a thin adaptation layer to let even unmodified WP7 app binaries run on the desktop Windows .NET Framework with the WinRT projection and to allow slightly modified WP7 apps to look good in landscape mode on both Windows 8 and WP8. If we had done that instead of making UWP XAML its own thing, and if we had integrated the Windows Store with the Windows Phone Marketplace from the beginning so that Windows and Windows Phone apps could be sold as variants of each other through a single Store/Marketplace product entry on Windows 8 GA day, then I think we could have brought a lot of people forward who were already making good WP7 apps, and the Store wouldn't have been so empty.
Furthermore, IIRC much of the original UWP XAML implementation was done by the original people who built WPF and Silverlight the first time, and they would have known what they were doing in separating UWP XAML from Phone Silverlight. That they didn't go in the direction of extending Phone Silverlight was not necessarily shortsightedness on the part of provincial Windows people. Maybe they thought Phone Silverlight actually demonstrated fundamental limitations of WPF or Silverlight XAML or the Silverlight "coreCLR", or they wanted to make breaking changes as lessons learned from Phone Silverlight, which was put together about as hurriedly. (Windows Mobile 6 -> Windows Phone 7 first previews = 1.5 years; Windows 7 -> Windows 8 first previews = 1.5-2 years, tending toward 1.5 years if you account for the frantic re-planning after iPad came out in early 2010.)
> 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.
It's important to remember the specific reasons why Windows RT 8 chose to not support third-party desktop apps. The most important aspect of "iPad compete" that we wanted on Windows for ARM was not "all app UXes look and work well on touchscreen tablets" but "you can't ship malware, not even by rebuilding your x86 malware from source." Thus, every 3rd party app on Windows RT would have to live in the AppContainer sandbox that UWP apps are in by default, and the requirement that you ship through the artist formerly known as the Windows Store would be a second line of defense against malicious apps. And with the forced-enabled Secure Boot, subverting the user-mode controls by secretly installing a bootkit would be hard even with physical access to the PC.
Even within the Microsoft world only, Windows Phone 7 had proven the success of this approach of locked-down apps only available through an app store that checked apps on submission and afterward for security. It was not unreasonable to think that similar lessons might also benefit users of "big" Windows, which is why Windows 10 and 11 have the opt-out "S mode" which defaults to the Windows RT restrictions.
I do wish though that Windows 8 had learned different lessons from WP7 (about which more in another point).
> 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.
fair. but that struck me as strange even then. if anything, visual studio should have adopted the all-lowercase typography of the original metro-style design language from zune and windows phone 7, not AN ALL-UPPERCASE ONE.
Perhaps that was just another way that Windows 8 Metro-style apps' design and developer platform was like Windows Phone 7's Metro style, yet different in seemingly gratuitous ways. That is something I would attribute to internal Microsoft politics. Steven Sinofsky and Terry Myerson (leader of Windows Phone at that time) never really got along, and in the Microsoft philosophy of that era where engineering divisions were completely locked down from each other by default, that rivalry would have discouraged what little natural collaboration would have happened anyway.
> I 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.
I think the real mistake there was not so much that a particular projection of the Windows Runtime was stopped, but the more general idea that developers should be forced to consume what became known as the Universal Windows Platform or author custom WinRT components through only Microsoft-made WinRT projections.
In the name of winning over new or inexperienced Windows developers with "simpler, safer" projections, we in the Windows division almost completely failed for about 5 years to document or even explicitly say that WinRT was essentially just "COM: The Good Parts, Version 2012". (Martyn Lovell's Build talks on the origin of WinRT were a notable exception to this.) This discouraged people from using their existing COM skills to develop Metro-style/UWP apps or to gradually adopt features from UWP APIs that were accessible to them in their existing desktop apps. Other people have written that "WinRT=COM" thinking is actually a bad idea because it forces people to deal with COM and its more annoying ideas (separate IDL etc.); I disagree because we should have reached out to people who live in COM world to get a ready developer base.
That mistake was a key part of the still larger mistake you touched on of trying to make the UWP and desktop worlds 2 completely different developer platforms that happen to co-exist on the same desktop edition of the Windows OS. That was the key "we didn't listen to developers" mistake that set up UWP for its market failure. Another example: Even today, you can't adopt the battery-friendly UWP app lifecycle using Windows App SDK, which is supposed to be the UWP successor for desktop app developers. So much for WinAppSDK (or indeed UWP/Metro-style apps in Win8) enabling a true no-compromise user experience.
It took real tours-de-force like Kenny Kerr building C++/WinRT and blogging about it, Raymond Chen blogging about using WinRT APIs through the unprojected "ABI" interfaces, or the VideoLAN organization building a Win8/Win10 UWP version of VLC in C, to get the word out that the UWP world wasn't some alien thing with dark magic that only Microsoft wizards had full access to. And it doesn't help that the wizards really do have a few special powers that they jealously guard even now.
> 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.
> 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.
That was at least in part due to the aforementioned obsession with iPad and generally mobile. One thing that Sinofsky is not wrong about in his post is that the classic Win32 app model is not conductive to good battery life - there's very little there to properly handle things like automatic background suspension or low-power push notifications. WinRT was designed with that in mind, but that would make no difference if the apps would just ignore it, hence the heavy-handed push for WinRT apps only (AFAIR it wasn't restricted to Store, although you had to jump through some "developer mode" hoops to deploy apps directly).
The main reason Win32 can't handle automatic background suspension or low-power push notifications is simply that those features haven't been exposed to it. There's nothing preventing a Win32 program from receiving those types of notifications and then being force-ended by the OS if it doesn't respond in time.
When I first started porting programs to Windows ARM64, I didn't have an ARM64 device and had to test in QEMU. It ran extremely slowly, probably 1/50th of real time. All UWP programs like Calculator ran like a slug. But which programs still ran reasonably? Classic WinDbg and Task Manager. Two programs that were still plain Win32.
There are significant issues with Win32, namely its lack of a permissions and isolation and lack of hardware acceleration in the old windowing UI (User/GDI). But the idea that Win32 is inherently power inefficient is, IMO, just BS. Its roots go back to CPUs that were orders of magnitude slower than modern CPUs and there is nothing difficult about making a Win32 program that idles at 0% CPU when not in use.
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."
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.
The .NET JIT compiler absolutely does query CPUID flags and generates different optimized code depending on available features, as well as the performance profile of each CPU model. This is similar to always passing `-march=native` to GCC.
This can have a huge effect on a wide range of applications, not just those using particular CPU features. For example, each libc implementation typically has a separate implementation `memcpy()` for each set of CPU features.
Okay thank you. I need to read more on the subject the.
The "Performance Improvements in .NET" blog lists the new JIT support for instruction sets each year.
https://devblogs.microsoft.com/dotnet/performance-improvemen...
> 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.
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.
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
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.
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
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.
Agree, and this is my point. Apple absolutely has a very clear message on how developers should make software, but as you say, developers often do not care.
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.
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.
Tbh Qt is so big you've still got a few minutes of decision making after you've decided to use it. What parts will you use and how will you use them?
...but then feeling out of place on GNOME / GTK4 / LibAdwaita-land
Linux is a mess, but at least it's unapologetically so.
They've got unified themes that make GTK and Qt applications look nice alongside each other. Users who care will be using those. Users who really care might refuse to use your application because it isn't the toolkit they like, but you shouldn't lose sleep over satisfying such particular and demanding users. They're not paying you anyway.
Delphi (or Free Pascal+Lazarus) and Visual Basic had this capability (to easily spin up GUI). It was called RAD.
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?
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.
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.
You might have sold me on this, because on top of the productivity-ish stuff I do, I'd really love to get into VST development. If I hadn't fallen into Photoshop plugins first, I would always have been an audio plugin dev. I loved PSP VintageWarmer in the late 90s.
The UI in Rowland's demo at 32min is feeling a little DearImGui / Reaper-ish, kinda bland while also being non-native. But I've seen all the UIs that Arturia & everyone else makes with JUCE, even what Valhalla does with it with their NASA inspired interfaces, so it can clearly make amazing stuff.
I can't believe we're now looking to PACE of all companies to help indie devs. I hated iLok for so long even though I have two iLok dongles now ;)
Well, I hope you will take a serious look at it as a technology stack worth learning, because when you get things rigged up so that you can really just push your changes into a repo and get the builds for all platforms, its some kind of magic, and you will - most likely - be really inspired to create something great.
Which, I hope, you do.
(PS; - the default UI skin is, imho, intentionally a tad bland in order to promote developer uptake of JUCE' pretty amazing skinning/UIBehaviour system...)
Qt Small Business pricing is very reasonable.
I think I prefer that JUCE is a one-off licence at $800 (for small business) and that they offer a 30% discount if you want to upgrade when they release a new major framework version. I'd rather not get locked into Qt's annual $618/subscription every year just to continue distribution & development.
But Qt has the bonus of also running on HaikuOS, and I've definitely seen more business apps in Qt (pretty sure 010 Editor is Qt).
You can also use LGPL. You only need to disclose the changes you made into Qt itself and allow changing it with another DLL. That's it.
Some modules, such as QtCharts, aren't available in the LGPL version.
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.
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++.
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...
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.
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.
>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.
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).
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.
> 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.
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.
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.
> 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.
> 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.
All that and they abandoned it at birth. It never felt finished and got little to no attention for years.
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.
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.
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
I've worked inside the Microsoft 365/SharePoint ecosystem for over 20 years, and the incoherence runs deeper than the GUI layer.
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.
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.
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
The summary of various frameworks and languages available is very concise and informative though.
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.
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
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.
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.
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.
This is true until it isn't though. Blackberry was doing great with enterprise users until people refused to give up their iPhones even at work.
The end state of genAI is that the end user is the enterprise
The end state of genAI could as well be a few billionaires being their enterprise and everybody else being unemployed or working at the factory. Robots are not there yet (far from it) and someone needs to build and maintain the thing as well as food for everyone. High unemployment could drive salaries down and make lots of thing unavailable to the common people while making humans cheaper than automation for boring manual work.
That's an extreme scenario but today's politicians are not very keen into redistribution of wealth or prevention of excessive accumulation of economic power leading to exceeding the power of the state itself. I see nothing preventing that scenario from happening.
> High unemployment could drive salaries down and make lots of thing unavailable to the common people while making humans cheaper than automation for boring manual work.
‘I wanted a machine to do the dishes for me so I could concentrate on my art, and what I got was a machine to do the art so now I’m the one doing the dishes’
But you already have a machine that can do the dishes. Like doing the laundry, people forget the machines they already have doing 90% of the work. Soon enough artists will forget that computers can do 90% of their work too.
The French will lead the way.
The French are on their way to put a far-right government in power next year, don't count on them.
I imagine that the rabble will need to eat only a few before the rest catch on.
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.
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%).
[flagged]
Yeah of course. He has nothing to do with Microsoft operations or strategy. But does he still use the products?
He still visits Microsoft occasionally. A friend showed me a picture of him visiting Microsoft in Beijing a few months ago (he was excited about BillG visiting). So my guess is that he still has an interest in Microsoft products.
I couldn’t know, but generally speaking, older billionaires don’t typically interact with the world in the same way most of us do (well, those without a social media addiction anyway). The device is someone else’s problem.
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.
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!
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.
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.
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".
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/
The writing style was really poor. Too many words saying too few things.
Entirely AI. I just can't with this style anymore.
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.
The slop-typos aside, "Jeffrey Snover" is just completely wrong all over his infographic.
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?
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.
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.
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
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.
For some reason I associate this with this article
https://blog.hiler.eu/win32-the-only-stable-abi/
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.
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.
That might have been more significant had the Windows Runtime not been effectively locked off to Metro-style apps. You could technically use it from a desktop app, but almost all of its functionality was only allowed within a Metro-style app, often due to requiring a core window or package identity. Even today the vast majority of useful WinRT APIs, including the entire UI system, require UWP or package identity.
Package Identity isn't that different from Signed COM Registration of the ancient past. Microsoft built up a lot of dislike from it by building it "sandbox-first", but the core of it still isn't that different from COM's ancient footpaths, at least to the COM diehards that hate .NET and didn't learn near enough from .NET's battles with the same things in terms of package signing, CAS (Code Access Security), and the GAC (Global Assembly Cache).
"Sandbox-first" even made some sense as a direction to work because it is harder to add a sandbox after the fact than to start with one, which is one of the core lessons learned from XP trying to sandbox some of the insecurities in Win32 and getting caught in a lot of complications. (The "sandbox-first" of UWP wasn't even that different under the hood from the XP "sandbox" of Folder/Registry Redirection, just a little better hardened.) Microsoft needed a lot better messaging up front if they had expected to allow more apps to leave the sandbox eventually. But Microsoft probably did believe the UWP sandbox was a better and safer experience for consumers.
But yeah, what's left of Package Identity outside of the sandbox feels like it includes several classic mistakes from .NET's CAS/GAC era, and also seems to point out that Sinofsky was wrong about WinRT "respecting the past" when it failed to learn from that era because it didn't trust .NET's history.
One significant difference is that Metro/UWP requires signing for pretty much everything. Without signing you can't have package identity, and without package identity, you can't even use the UI system. Furthermore, it requires a paid cert, which is expensive and requires publicly divulging your identity. I have major problems with this as it opens developers up to harassment. .NET at least allowed self-signed certs.
It's true that there is no great answer for how to add capabilities and sandboxing after the fact. But what Windows did was build an incredibly restrictive sandbox and then tell everyone who couldn't accommodate even one of the restrictions was "sucks to be you". The result was that developers, when confronted with "all or nothing" for Metro-style apps, were forced to choose nothing. It was also not a good look that Microsoft's own flagship applications like Visual Studio and Office did not show any progress toward adopting UWP, and in the latter case, was specifically exempted from the Windows RT restrictions to continue using Win32 on that platform.
If there had been a better strategy for easing in UWP technology, we might have seen better progress on adoption of Windows Runtime APIs and capabilities so new programs could gradually move toward the new technologies and away from HWNDs. Unfortunately, the technical barriers that were put in place between Win32 and UWP are so large that progress toward breaking them down in the Windows App SDK has been slow.
> .NET at least allowed self-signed certs.
The GAC and certain CAS configurations would require paid certificates, too. Certainly the requirement of paid certificates can be seen as a part of how both of those eventually fell out of favor. That is another of the things I felt UWP missed learning from .NET. Developers do generally dislike code signing certificates and try to avoid them.
Also to be fair, UWP had a rather streamlined certificate system if you targeted only the Store and let the Store manage your certificate chain. It was even a little bit easier to use than Apple's similar App Store management of XCode certificates. Not that that was a high bar to clear.
> It was also not a good look that Microsoft's own flagship applications like Visual Studio and Office did not show any progress toward adopting UWP
There was some progress. Office involves a lot of teams working at different paces and sometimes extremely different codebases. OneNote was fully UWP for a while and was at one point considered a flagship and testbed for UWP "Fluent Design" (both before and after the shift from touch-first to the over-correction to "it's just a desktop framework that sometimes is touch friendly"). Several new Office apps were written UWP first, including the "Office Hub" app that became called just "Office" and now is even more confusing called "Microsoft Copilot 365 app". "Outlook (New)" has always been React Native, but as a React Native project, it ran entirely in UWP, too, for a while. It was said to have been one of the drivers for deep UWP support in React native at the time. There were also the React Native-based Word, Excel, and PowerPoint "mini" versions that ran entirely in UWP. Those are said to have influenced more of the real codebases pushing towards React Native, but did not try to replace the original codebases in the same way that "Outlook (New)" today is overtaking "Outlook (Classic)".
There were a lot of strategy problems with UWP, but adoption was further along in some areas than it looked.
There are still some things that are still locked in the UWP world that I wish were not.
For example, Windows classic desktop apps still have no equivalent to the UWP app lifecycle. Your UWP app's processes can be suspended and resumed without you writing code to force the suspension and request when to be resumed later. Instead, you are expected to appropriately handle event notifications for suspend, resume, and the app entering and leaving background state.
This system-managed UWP app lifecycle makes life harder for UWP app authors, but I think the net win for battery life is much better for the user experience, which is why mobile apps operate the same way. Yet the docs for the Windows App SDK, which is supposed to bring the best of the UWP to desktop apps, explicitly say that WinAppSDK apps control their lifecycle just like other desktop apps, and the only power friendliness in the WinAppSDK API is voluntary (aka no one will use it). [1, 2]
I'll probably write more soon in response to other parts of the original link's comment thread. Overall, I feel like UWP is being unfairly maligned here, and that while its introduction was unforgivably arrogant, Steven Sinofsky is also right that it was daring and necessary to fix the mistakes and outdated decisions of 16-bit Windows and Win32.
[1] https://learn.microsoft.com/windows/apps/windows-app-sdk/app...
[2] https://learn.microsoft.com/windows/apps/windows-app-sdk/app...
Those are some good points, and I especially loved that lifecycle management in the era where I used a lot of Windows 8 apps. Even on a Desktop with apps filling up my screen still seeing some of them pinned to 0% CPU most of the time (while I'm multi-tasking) in Task Manager was a delightful magic. I also agree that was one of the best parts of the UWP sandbox and one of the biggest shames when Microsoft had to figure out how to allow sandbox breaks that they couldn't find a way to make the lifecycle and other smarts parts of the sandbox more opt-out by default rather than "opt back into the full sandbox". Of course needing to opt-out by default was one of the reasons developers hated the sandbox in the first place. It's a marketing challenge no matter how you slice it.
That relates to some of my criticism that maybe UWP could have used more .NET veterans because that was one of the problems with the CAS sandbox. For the most part the CAS sandbox was "opt-in" and yeah software developers through ego, hubris, and everything else will most often declare "my app/library is a special snowflake and needs access to everything!" So even if things opt-in to additional security controls like CAS, no one tests or builds for Production in a CAS sandbox so even things that claimed to support CAS threw runtime exceptions all over the place to the point no one could trust CAS to the point were CAS died for being practically useless overhead because no one both opted in and knew how to test it.
UWP had a lot of good ideas. It's insistence that it didn't have much to learn from .NET's mistakes was not one of them.
“Retired general criticises the Pentagon” is practically a trope.
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.
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.
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.
I thought we're not discussing whether we like one UI over another but whether an OS's UI was (internally) consistent. You may dislike KDE, but it uses it's design language all throughout the UI from window manager, the application launcher, the settings dialog, everywhere. Windows famously has three (or more?) styles of control panel UI. You may prefer that, and to each their own, but it is inconsistent, which was the topic of this thread.
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.
Problem is, both Firefox and Chrome look out of place on it when you use a non-standard color scheme. Custom keyboard shortcuts won't work on Chrome. When you change a theme from light to dark and vice versa, both browsers like to have text in their UI stuck on the wrong color.
I could use Konqueror, I guess, but its ad blocking plugin (and plugins overall) seems to never have progressed much since KDE 2.
Right, applications can break all sorts of UI consistency. But the question is: do the standard components that the vendor ships do it? I argue: KDE is consistent. I don't want my desktop UI to dictate how an app draws its UI (or games would be impossible).
> But the question is: do the standard components that the vendor ships do it? I argue: KDE is consistent.
Well yes, I do agree with this. Internally it's mostly consistent, at least more so than Windows. Never analysed its UI structures though.
> I don't want my desktop UI to dictate how an app draws its UI (or games would be impossible).
As a platform, ensuring applications running on top of it stay consistent to varying degree is the job of the desktop/OS IMO. To what degree depends on the context, https://asktog.com/atc/principles-of-interaction-design/#con... is a great read.
Even games need it, missing input field features has plagued PC games for decades and can be crippling for input method users, Skyrim's console needs mods to support copy and paste. Custom mouse acceleration curves is the reason everyone disabled it, zero acceleration is the easiest way to make different games handle mouse input consistently.
A shame Linux isn't standardised enough.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Petzold is a legendary programmer. His book Code is worth reading: https://en.wikipedia.org/wiki/Code:_The_Hidden_Language_of_C...
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?
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.
Couldn’t someone do a similar story about scripting on windows, and make Jeffrey Snover one of the punchlines?
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".
This 2018 video from TechAltar discusses the same topic: Why Microsoft Can't Design A Consistent Windows (https://youtu.be/hn5QjtpjW_U)
> 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!
I think that is an insult to MS Bob
Petzold literally had the Windows logo tattooed on his arm. He was a true believer.
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.
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
"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.
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.
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.
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.
Uh huh.
I think you're comparing hand-writing an HTML/CSS interface to the WYSIWYG form editor of Qt or Visual Studio? Because hand writing a GUI in Qt/QML/C++/.NET is not any easier than writing it in HTML. There are tons of boilerplate and special markup to learn. The magical editor just hides all the plumbing from you.
I'll grant you that the lack of good WYSIWYG designers for working on web/electron apps is appalling, it's like RAD peaked in 1998 with VB6 and it's been downhill ever since.
Not having to round trip through ACL/security checks.
Not having to deal with state management.
Not having to deal with browser compatibility issues (and mobile vs desktop).
Not having to deal with weird input validation stuff dual layer stuff that is inherent in web apps, but not a big deal elsewhere.
Not having to deal with laggy and unstable connections at the UI layer.
Etc, etc.
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...
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.
It was more despised for being a gaping security hole than anything else, as I recall - the things you could do with it were really neat demos, but even back then, I said "I am not loading a random website that can access local things every time I log in".
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.
That’s the strategy of 20 years ago.
> sufficiently performant
In no universe is HTML performant compared to actual desktop applications. It sucks big time.
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.
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.
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.
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 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
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.
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. "
> 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.
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.
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.
Has anyone tried turning Microsoft off and on again?
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...
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.
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.
OLE objects are just like disk images.
Honorable Mention: Lazarus
funny thing is, with AI, it's become really easy to put win32 apps together, and they load fast and are super responsive!
Talk about UI without pictures!
s/\sGUI\s/\s/g
It’s web. Just use electron or Tauri.
WPF marked the end of well thought-out UI’s and standards. It’s been web-inspired slop ever since.
The slop image at the end made not read anything in this article.
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.
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.
I felt fatigued after the second paragraph. All these LLM tropes chained together are horrible to read.
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.
I think you should look at the graphic. It's riddled with inaccuracies and nearly-unreadable spelling mistakes and mangled typography. I think that's plenty of a good reason to flag it.
I think it really abuses the assumption of good faith and the default to generous interpretation, because it forces you to divorce the author from their own published work in order to view them seriously. I suspect most of the comments here are generously ignoring the included graphic. But in the most generous view possible, the author is fine with publishing wildly inaccurate statements.
I think this makes HackerNews much worse, and posts like these should only be flagged.
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?In a more generous interpretation, there was silence, _then_ people said something. That makes sense.
But "That silence is the story." is still a pretty telling non-sequitr, and it doesn't seem like the kind that comes from sloppy editing.
The punchy "Thing. Thing. Thing." is used constantly. We see it constantly in this article:
> 852 pages. Win16 API in C.
> Message loops. Window procedures. GDI.
> One OS, one API, one language, one book.
But those are minor sins. But in the end of the article, Snover states that Microsoft pitched C++ in 2012. That's so incorrect! The contents of this blog post are at least partially falsified.
Plus, the thesis statement is nonsense:
> When a platform can’t answer “how should I build a UI?” in under ten seconds, it has failed its developers. Full stop.
"Full stop" is a pretty heavy thing to end a nonsense statement with. How an inanimate software platform can "answer" things is not implicitly obvious, either. Is it a human representative? Are they the docs? Is it through a good UI?
The post is about Petzold's / Reccold's "Programming Windows", but it is apparently 852 pages, so that certainly wasn't answered in under 10 seconds either.
He immediately said they never did make a decision, so probably that indecision.
Having said that, this article feels like AI slop to me. Couldn’t get through it.
Just have a look at the final picture if you're unsure if it's slop
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.
[dead]
[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.
Yes, those are all different versions of the underlying widget frameworks. I don't understand your point. My current GUI is KDE Plasma 6.6. The only libraries I have installed are Qt 6 (which I am not sure why you didn't list). I have no need for version 5 or 4, or any other. The GUI is consistent.
When I last used Windows, on a fresh install, I saw a mixture of different frameworks used for core OS components from the same vendor.
When I last used OS X, it was pretty consistent but I hear complaints from friends that its no longer the case.
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 would recommend Flutter, if Google would not have abandoned it. 12000 open issues on GitHub speak for themselves.
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.