Ask HN: What is the best way to build a desktop app in Windows in 2023?
I’m talking the most native look and feel for the Windows platform.
Is it XAML and C#?
Is it XAML and C#?
https://learn.microsoft.com/en-us/windows/apps/winui/winui3/
Disclosure: I work at Microsoft on a team that works on visual look and feel for Windows.
The look and feel is great though, Win11 is a nice step up from 8/10 in that department. So good to have depth, curves, transparency, etc back again.
https://microsoft.github.io/windows-docs-rs/doc/windows/UI/i...
WinForms is very old and doesn't do DPI, but one thing I like about it is that it always works.
By comparison when Windows 7 was released, enabling glass was documented and usable from any language or framework.
It's also not currently possible as far as I know to mix new controls and old controls in one window very easily - there are islands, but they seem on the macro scale (from when I last looked.) This makes updating apps difficult: changing a UI is an all or nothing upgrade per window. You can't just easily add WinUI to an existing WinAPI window in an app using a non-C#/Microsoft language. So people who have existing apps or use a non-MS dev environment are faced with enormous barriers.
The ties to Microsoft languages and IDEs are also troubling. It's not technically MS-only, but it is _effectively_ MS-only.
This is my personal account (I don't have a professional HN account) but I work at a company that produces a dev environment and IDE, and we run into these issues. I find that searching for my HN username and LinkedIn ("vintagedave LinkedIn") will likely let any reader (the OP, any reader, or u/ fassssst if you'd like to get in touch?) find me, and I'd be happy to speak on a personal or potentially professional level about issues with WinUI and what could be done to make it more accessible across dev environments and more easy to convert to or upgrade to.
This always infuriated me on Windows, and a big reason I moved to macOS.
This is a great read: https://arstechnica.com/features/2012/10/windows-8-and-winrt...
> ...the biggest problem is that USER [API] is essentially inextensible. If a developer wants to create, say, a menu that acts exactly like the standard operating system menu but with some small extra feature (for example, he might want to support the drag and drop, similar to the Favorites menu in Internet Explorer) he generally has no option but to reinvent the entire menu system from scratch.
Seems like the failure of the Longhorn project really messed things up. It was suppose to replace the janky old win32 with .NET managed APIs.
I just remember XAML/WPF/.NET being incredibly slow. And choosing a managed language for OS stuff seemed bad. I can't believe no one was doing a quick POC and saying: this is too slow.
You have to give credit to Apple platform team. They have some real visionaries there. They had the guts to ignore garbage collection even when it was taking over the entire software industry. I guess MS just needed a competitor for Java.
I'm sorry, but this is a massive step back in usability. I'm not moving from a system where I can drag/drop UI elements into place to one where I can't.
I have never had so much confusion in my life. WinUI 2, WinUI 3, C++/WinRT, C#/WinRT, C++/CX, C++/CLI, WinRT (Windows Runtime - that's not a runtime), COM, C++ Win32, C# .NET, UWP, Fluent, Metro, .NET MAUI, PWA, React Native for Windows, WPF, Windows Forms, Windows API, Windows App SDK (which is WinUI 3), VSIX, XAML, .winmd, WebView2.
When I think about macOS: Swift + SwiftUI, Swift/ObjC + AppKit.
This article was a huge read but helped me get an idea of things: https://arstechnica.com/features/2012/10/windows-8-and-winrt...
I think the issue is that the writers are trying to be too delicate to not make people feel like their apps are using legacy technology that will be deprecated.
> Many apps for Windows are written using WPF or Windows Forms, and they remain viable tools today...looking to the future....
There should be one obvious recommended way to build new apps, and all the other docs should be moved to a separate section.
And when I install Visual Studio 2022, it has a "Workload" called "Universal Windows Platform"...but I just read this is deprecated!!
I honestly don't think Microsoft has the balls or ability to set a singular way forward at this point. WPF/UML have both been pieces of hot garbage. So one more framework to rule them all probably isn't something they're looking to explore at this point.
What should probably happen is that they make an announcement similar to that which they dis with printer drivers. "Beyond 2027, it must all look like this. Here is 4 years lead time. Get on the train."
ChatGPT gives a decent summary of the history of all that:
https://chat.openai.com/share/6478dcdd-98d3-449a-84be-be5666...
My own personal outsider take on this is that there are really only three eras that need to be considered:
- "HWND era": win16/win32 classic UI aka "WinForms". This extends all the way up to ActiveX. Microsoft get to dictate the platform without real competition.
- XAML era: the second system. Classic WinForms doesn't handle high-DPI displays or GPU rendering; it relies on pixel positioning and lets you draw directly on the framebuffer. WPF is the reaction to this.
- Phone era: suddenly there is real competition and users start using a lot of non-Microsoft platforms. Microsoft launch their own phone, complete with new sandboxed APIs that don't correspond to Win32 at all. This is ultimately a market failure. But Microsoft have invested too much in UWP.
At this point, the winning stacks globally are, in order: web (including Electron), iOS, Android. Nobody wants to do native Windows applications that aren't games if they can possibly help it. Even Microsoft start building web-on-desktop apps like Teams.
So the only thing Microsoft can do is salvage operations on UWP APIs and XAML-related techs to try to make it usable to desktop developers by getting out of the sandbox.
I had thought XAML was it and was ahead of the game, but it's kind of a different approach.
All the new ones define their declarative UI as inline source code.
I remember a while back there was contraversy that MS wanted people to write Windows apps for store in TypeScript. What happened to that?
https://learn.microsoft.com/en-us/power-apps/powerapps-overv...
Yeah. Unfortunately, Windows is not Python.
Even Python is not Python these days.
$ python
>import this
The overhead of WinUI3 is pretty huge. The visual designer, a winning feature of Visual Studio for decades, is AWOL. Why? It's XAML, the same as the previous XAML designer! It's just .. broken?
The backward compatibility story is a disaster: you can get stuck in the UWP sandbox https://github.com/microsoft/WindowsAppSDK/issues/1780
What's the big Microsoft WinUI3 flagship app, then? Something people are actually using? Rather than just a few system dialogues. (How many Win11 settings pop up a Win32 dialogue box, still?)
WinUI 2 and WinUI 3 currently share the same look and feel but new apps should use WinUI 3.
Other than apps written by the Windows team and shipped with Windows, what's the flagship WinUI3 app?
How large is the actual WinUI team, approximately? We can make guesses from the number of committers on github, which appears to be about half a dozen people? It just doesn't feel like Microsoft themselves are really committed to making it work and then forcing it on Office or Teams.
At some point soon I'm going to have to do a native app to do driver control, and it seems the elegant simplicity of WinForms has been lost compared to how much "runtime" nonsense is hiding underneath the two different WinUI2/3 implementations. (You've done a Python 3 there!)
(There is no native look and feel on Windows any more. Microsoft pissed on that concept a long time ago.)
Even the landing page for WinUI starts off by comparing the differences between two versions of it.
It feels like they are trying really hard not to annoy developers by telling them their stack is now legacy.
They should take all old technology and put it on an entirely different docs website.
> We've been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform. > >-- Steve Jobs - https://www.engadget.com/2010-04-10-steve-jobs-responds-to-c...
I've heard Steve say this a few times, and it always caused developer backlash. But having seen how things have played out, I think he was definitely right.
Honestly though, Windows should have just gone with HTML. The majority of HTML-based apps are nicer looking and feeling than Windows apps, and the perf is fine. I just don't know how they f'd up XAML/WPF so badly.
[0] https://microsoft.github.io/react-native-windows/ [1] https://microsoft.github.io/react-native-windows/resources-s...
This is not to say that React Native is good.
Teams tries to be your new desktop, it provides a file browser, calendar, meeting scheduling, access to edit your Office documents and take One Notes. It reminds me of an alternative shell for Windows 95.
It also has an embedded chat app. This embedded chat app has new messages at top on some tabs, and new at bottom on other tabs. It prevents me from having more than one chat open. This chat app only supports RTF for formatting (who the fuck still uses RTF?) which means it struggles to process markdown and other rich formatting. Pasting some text that it decides is going in a box can be laborious to remove.
It's just a bad app.
WhatsApp Desktop uses WinUI.
WhatsApp is superior.
I don't get React Native. It's such a huge, complicated abstraction with no ability to performance tweak. I don't understand how a company as big as Facebook doesn't have enough resources to build native apps for each platform. These UIs are the simplest app you could build as well.
This is misleading at best, if not outright wrong.
You can put together small applications in minutes.
Lazarus is free, but due to the way their help files are build, incremental improvements in it are impossible, so it's just a list of arguments for functions, with no real explanations.
That's a good point about popular languages, but you can't complain about Dephi's staying power. Wikipedia shows it as having been released in 1995, and it still seems to be going!
Yes, but it's only really alive due to legacy systems. You don't often see new development done on it, at least in the US. Good luck finding a Delphi developer vs. Java or C#. I think it's still popular in Eastern Europe though.
I do love the platform and I used it for probably 13 years, but it's wilting pretty hard today. I would never build anything of substance with it today.
* Bloc (UI framework)
* The stuff in their new presentation (will be online in a few months)
* Pharo
You could get pretty far.
For example, this game [1] has been packaged as a Win/Mac app [2].
My problem is that, in 2023, Pharo still doesn't support high DPI displays, which means it's a blurry mess on every single display currently in my house.
It's blurry on my M1 MacBook Pro, on my PC with Windows 11, and on the Lenovo X1 with Ubuntu I owned briefly during the pandemic. It's blurry on all the external monitors I own. If I could run it on my iPad, I bet it would be blurry on my iPad too.
Bumping up the font size in the IDE settins is a reasonable workaround for this issue, but it's not a good long-term solution. While it makes the text in the IDE readable, other UI elements are still either comically tiny or blurry, depending on your settings. Sometimes there are some UI elements that scale up with the font size, and others that don't, which results in an inconsistent UI that's hard to use.
MacBooks have had "retina" screens since 2012, and 4k displays are increasingly becoming more common. I hope Pharo will eventually support proper UI scaling, because I can't try out your cool futuristic IDE if I can't even see it properly!
If Teams, Office, and VS Code are any indicators it is web-based technologies:
https://techcommunity.microsoft.com/t5/microsoft-365-blog/4-...
https://support.microsoft.com/en-us/office/office-is-now-mic...
The interface of the app is C#, the core is in CPP (I am tempted to use Zig but haven't worked with it enough to commit to it yet).
I always wondered why it took until Win UI _3_ to decouple...but I guess this is why.
(edit: crucially I don't think you can use either of those with dotnet core?)
Otherwise another shot could be a Java/JavaFX application, possibility compiled natively or packaged with jpackage, so you deliver your own tailored JVM, without requiring the installation of a JRE on the user system.
Another way would be to embrace the Microsoft ecosystem with the Windows UI Frameworks and then use C# or C++
I remember when the Ribbon UI came out. And there were like 10 different vendors making all different ones, each with a different look and feel.
Just like Amazon took internal services and made them exposable in AWS, so should Microsoft with every UI component they build. You shouldn't be able to ship any UI internally, unless you make it publically accessible. I guess WinUI 3 is heading in these direction by decoupling from the OS. But boy it took a lot of time!
It is possible to be both.
I have been using aardio to develop desktop software for more than 4 years. I have developed many software. It is designed specifically for Windows desktop.
- Based on the syntax of Lua and JS, if you have one of these 2 foundations, you can get started in 1 hour. - Comes with an IDE, developing, compiling, debugging, rich standard libraries and sample code. - Support WYSIWYG UI control drag-and-drop. - Supports WebView2 and native development mixed - Support the use of Python, Go, C#, etc., can be used as a glue language. - The size of the packaged file is very small - The IDE and tutorials, documentation, and IntelliSense are only available in Chinese, but by using translation, it shouldn't be too much of a problem. For experienced programmers, it is easy to understand.
- Still supported on latest .NET
- Most feature rich and battle tested
- Good documentation
- You will learn XAML which can be later used once when WinUI 3.0 is more mature (at least another 5,6 years will be needed with their current development velocity)
PS.
XAML is a bit different but similiar enoguh between WPF and WinUI.
Of course it depends on what type of application.
https://learn.microsoft.com/en-us/dotnet/desktop/?view=netde...
Since PWAs run in the browser of choice, they are definitely native, especially if you choose Edge, which is approaching dominance on the platform.
PWAs grant automatic cross-platform ability. I can install and run PWA in Windows, Android, ChromeOS, you name it.
Also it is super minimum hassle. Windows never bothers me about the Store, or signing, or updating any PWA; it's simply transparent.
QT is great, until it's not, then it sucks.
It was a fairly complex desktop app that did a number of interesting things in the domain of graphics too.
It was a simple C++ and QT app, with the necessary domain-specific libraries.
If you need to develop a non-trivial gui app in windows then C++ and QT is a great combo.
What underlying tech does it use for rendering on Windows?
There is even a dart package which recreates the Windows ui very well!
And the builds was very small! Barely a couple of MBs.
By career I'm mostly a C# person but (IMHO) everything desktop UI that Microsoft have done since WinForms has proven to be not worth using for the long (or even medium) term.
Or you can look into https://tauri.app/
wxWidgets is not and things may have changed but my experience with most cross-platform libraries back in the day was that they could get close but never get real native UI experience.
It is the only cross-platform library that uses native Windows controls. Qt? Emulated. GTK? Only native in Gnome, emulated on Windows.
Even the new APIs, like WinUI, from Microsoft, are less native than wxWidgets.
That leaves the opportunity of the future to the community. And I think we want to convey the message that 1. We have web UI options, so don't reinvent that wheel. 2. Windows is not web, so give us a UI that is desktop-centric. And in that vein, people use desktop for complex tasks, so don't try to force Windows into colorful Duplo-sized buttons and style (don't make Windows web: i'm looking at you WinUI, Xamarin,etc; all more recent Microsoft offerings ditch the complexity and move toward web design). We demand feature rich, deep, complex systems.
WPF is the most advanced UI designer ever created. WPF was made open-source (mostly) and then mothballed. It's way too complex to build from source and they are accepting nearly zero PRs from non-Microsoft sources. Maybe the move to send WPF management to the India team was a possible way to increase activity around WPF (since its repo has been drydocked and managed by like 3 people for years).
Avalonia is nice, but not nearly as capable.
I would love a potential future to be Microsoft dusting off WPF and getting serious about open-source. Fix some infrastructural problems like building from source that allow developers to begin exploring how to rebuild the rendering engine, preferably using something GPU-driven like OpenGL. There is a lot of excitement in the realm of using game engines to render UI, it would be great to have some team members be architects to design the retained-mode side of the UI interfacing with team members that are immediate mode designers, think OpenGL, Vulkan, etc. Having looked through the WPF source code, this is pretty much how it was, the WPF logic interfacing with Windows draw calls. It's just outdated.
WPF isn't fully open source, which is a huge problem. A lot of the low level graphics calls are still calling to non-open-source Windows libraries, so it's really opaque how to modularize the rendering calls. Microsoft needs to spend a year devoting a team to internally forking Win32 and then building interfaces for every WPF call into non-open-source rendering code. Then the community can actually fork some alternatives using modern graphics renderers.
I don't think we will ever see this though. Microsoft, despite languishing as a market-mover, has too much temerity to give the community this kind of control over it's core. They want WPF as an "outdated" technology to be reliant on Win32, instead of wanting it to be replaced with something more modern. They will happily keep releasing incomplete and remedial UI frameworks built atop antiquated DirectX forever.
Beauty is in the eye of the beholder. Even Windows 2.0 looks better than Teams.