There is no "free" version, only a "if you make less than $X" version, which is a huge red flag for me.
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.
Ah, interesting. $5000 isn’t a lot for professional software developers but could be fine for hobby projects I guess. $1300 for the professional version is a steep price jump from $0
Delphi was quite good at Windows application development last time I used it, probably 2010. I'd probably stay away if you ever need to maintain it or hire people to use it. There's value in using a popular language with staying power.
> There's value in using a popular language with staying power.
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!
>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.
The answer is: pick your poison. There is no best way. Microsoft would have you believe it is WinUI, but there is also WinForms, WPF, UDP, Xamarin Forms, .NET MAUI, Avalonia, Uno, and several other solutions.
Even the landing page for WinUI starts off by comparing the differences between two versions of it.
> 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.
They decoupled the UI framework from the OS in WinUI 3.0. The point of UWP was that it used controls and rendering capabilities built into the OS. This resulted in performance regressions and missing features for several versions compared to the 2.8 branch.
I tried writing an app using WinUI a few months ago and the widgets that it has are decent, but there are some major gaps compared to older Windows UI frameworks and Cocoa. The one that stands out most is its lack of a proper tableview/datagrid (think NSTableView in Cocoa). I know about the community widget but it doesn’t feel right to have to pull in a third party library for something so elementary.
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.
It's a shame that, unlike with Win32, using WinUI places pretty harsh restrictions on which programming languages and environments you can use. Only C# and C++ are supported, the latter only with Microsoft compilers. For everything else, including Rust[1], Python and MinGW C/C++, there is no answer for OP's question, and the effect of this on the visual consistency of the Windows desktop is obvious - there is none. Every third-party app uses a different toolkit with a different look and feel, because the library providing the standard look and feel simply isn't available to the majority of developers.
Not to mention that WinUI is not supported on Windows Server. Therefore, if you need to deploy to server and desktop environments, it's better to stay with WinApi (WinForms) or WPF.
It's really hard to use with Win32 / the traditional Windows API too. Often APIs aren't exposed or documented -- consider the APIs to turn on the Acrylic or Mica looks in a window background, for example. There are a few Github repos that show how to do it but using reverse engineered APIs or constants.
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.
> ...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.
Absolutely this. So much this. I dont give a shit about how modern you want the look and feel of everything to be. Sometimes I just need to not spend weeks pulling out my hair trying to wrap my head around something so basic and simple as a UI. Even VB 6 had ways to make stuff scale. Can't be that hard.
For someone coming back to Windows development after 5+ years, it is so incredibly difficult to figure out what is going on.
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.
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!!
You've just very eloquently listed out the Windows UI framework dumpster fire.
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."
That's not a bad summary for AI, but it is very funny that every step of the way gets the adjective "modern".
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.
You still can create a progressive web app and submit it to the Microsoft Store. Essentially the same as Win8 web apps but better since PWA’s use a Chromium-based web view. You don’t get native controls though.
.. and how many of the Microsoft applications actually use WinUI3? As far as I can tell they're doing their own thing (Office) or are Electron (Teams) or, at least in Windows 10, haven't actually been updated from WinForms.
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?
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?)
File Explorer is using it. Much of the Windows 11 shell, including the taskbar, Start menu, Settings, notifications, and Microsoft Store is using WinUI 2 (only because WinUI 3 wasn’t ready at the time). Even apps like Notepad, Paint, Sound Recorder and Media Player use WinUI.
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!)
You need to check whatever half-arsed framework "that will be universal and encompass everything" Microsoft is promoting this specific month, and then violently ignore it and use proven things like wxWidgets or WinForms instead.
(There is no native look and feel on Windows any more. Microsoft pissed on that concept a long time ago.)
I am using Avalonia. If I were doing windows only I might use MAUI or WPF or something but afaik they are pretty similar, and I want it to be cross platform on mac.
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 don't think they can kill it, ever. On the other hand, it looks old, and you'll forever have DPI awareness misery for cases like "two monitors with different resolutions".
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.
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.
You also need to do extra work to build in slots and signals, which tou don't need to do with many, many other frameworks. If tou don't put the extra work in learning that stuff, and it does require effort to learn, then you wind up with an application whose interface locks up if it's doing anything non UI related between UI calls.
Microsoft is using React Native for Windows [0] for their Office applications [1]. As a fan of RN this would be the first avenue I’d explore if I had to develop something for Windows.
Teams is, and it's IMO the worst Office app available. I don't have time to get into all the reasons why right now because I need to sleep and it always leads to a 30 minute irl rant or a multiparagraph screed about the complete breakdown of their corporate work culture and terrible UI tooling that they can't fix a context menu rendering bug in their own damn "native" first-party corporate communications app when _They're The Company Writing The UI/GFX API THAT REACT NATIVE USES!!!!_ hooooosaaaaa I don't work there anymore, I don't work there anymore. Good night HN.
Would appreciate if you could spare some time to elaborate. I’ve had pretty much the worst experience with Teams of all communication solutions. I just can’t figure out what’s going on with it. On Macs it constantly misbehaves. Is it due to RN?
No. Teams is a terrible application regardless of the UI Framework.
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.
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.
Both of these comments are strange, so I may be misunderstanding, but with any UI framework, one can make them look however they want through custom styles, design is not dictated through the framework itself but by the styles.
I will still place my bet for C++ combined with a third party UI Framework. I know that Qt has changed its license model, but it offers many capabilities and is battle-tested enough.
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 don't get how MS can't just build a control library. You always have to use these expensive third-party closed-source libraries.
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!
I really REALLY want to use Pharo to build something significant -- I love the ideas behind Smalltalk -- but I've been disappointed every time I've tried.
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!
- 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.
105 comments
[ 3.4 ms ] story [ 226 ms ] threadYou 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.
https://dotnet.microsoft.com/en-us/apps/maui
What underlying tech does it use for rendering on Windows?
Even the landing page for WinUI starts off by comparing the differences between two versions of it.
https://learn.microsoft.com/en-us/windows/apps/winui/
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.
https://learn.microsoft.com/en-us/dotnet/desktop/?view=netde...
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?)
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.
[1]: https://github.com/microsoft/windows-rs/pull/1836
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
https://en.m.wikipedia.org/wiki/Zen_of_Python
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.)
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).
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.
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.
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...
QT is great, until it's not, then it sucks.
[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.
Beauty is in the eye of the beholder. Even Windows 2.0 looks better than Teams.
It is possible to be both.
Or you can look into https://tauri.app/
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!
* 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].
[0] https://pharo.org
[1] https://github.com/Enzo-Demeulenaere/Takuzu
[2] https://github.com/tesonep/takuzu
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!
- 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.