Posted by naves 1 day ago
What's still missing is deeper integration with native OS concepts and programming languages other than JS. Frameworks like Electron are a step in that direction but they come with notable drawbacks. Applications often struggle with things that should feel natural like managing multiple OS-level windows.
Another PITA: Electron apps repeatedly bundle large portions of Chromium, leading to unnecessary overhead. Those duplicated modules lead to bloated RAM usage: every app has its own Chromium copy and OS must keep all that zoo in RAM without a possibility of reusing the otherwise shareable parts.
Orders of magnitude more BS, plumbing, awkwardness, head scratching, etc.
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 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.
In no universe is HTML performant compared to actual desktop applications. It sucks big time.
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.
It's all win32 underneath except for UWP, which is now deprecated.
so the answer is win32, raw winproc.
The issue is they haven't made a new GUI API (only frameworks) since win32.
The issue was they didn't give you an alternative they just said don't do that.
so inevitably at some point you decide to just write it in win32, don't ship in the store, etc so you can get things done.
Er… The author perhaps never used it? WPF was the worst framework I ever used. It was unbearably verbose, brutally unforgiving, used 2-way bindings that created updating nightmares, ans not the least it was incredibly slow.
WinForms was not the best for sure, but at least you can get stuff done. It was for a long time the right answer to the question the author asked. .Net + WinForms worked well.
When WPF shipped was when the shit hit the fan.
This is the common thread of all their frameworks since, and in my mind the reason they are stuck in an absolute quagmire. For a while it was possible to use HTML/JS in UWP (I think), but it didn't stick due to everyone already needing to move over their LOB apps with crazy amounts of XAML so that's what the focus was on.
"Hey, let's make something that's vaguely HTML but not really at all."
Big mistake.
Avalonia and Uno are repeating that mistake, even though with Uno, at least, there's a blessed way to do unidirectional data flow/reactive stuff.
Two-way data binding is the devil.
Microsoft developed VS Code and Teams in Electron. That says a lot about how they see the future.
>> 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...
Everything that came later was basically a struggle to make something that Electron actually delivered.