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.
https://microsoft.github.io/windows-docs-rs/doc/windows/UI/i...
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 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...
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 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.
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.
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.
You can put together small applications in minutes.
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!
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.
[0] https://microsoft.github.io/react-native-windows/ [1] https://microsoft.github.io/react-native-windows/resources-s...
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.
(edit: crucially I don't think you can use either of those with dotnet core?)
* 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!
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.
QT is great, until it's not, then it sucks.
Beauty is in the eye of the beholder. Even Windows 2.0 looks better than Teams.
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.
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).
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!
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.
(There is no native look and feel on Windows any more. Microsoft pissed on that concept a long time ago.)
- 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.
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.
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/
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.
