To paraphrase - what's the selling point of using Uno vs using .NET 5 and .NET MAUI (the successor of Xamarin.Forms) directly?
WinUI being the UI platform that Microsoft seems to be pushing on windows these days.
WinUI doesn't sit well with me - it has the same problem that all the other "user-mode" UI frameworks have: it isn't a system-service, so once your app ships it's frozen in time and won't benefit from new features added to native widgets and controls (e.g. if you run a well-designed MFC EXE last compiled for Windows 2000 - but tweak the embedded manifest resource file to load the updated CommonControls and Windows 10 compatibility - it will still look good today and fit-in with an MFC program created new last week (I note it will look "good" - not "amazing" - because Microsoft decided to take Windows 10's native widgets downmarket since Windows 8, ugh...).
Could be worse - at least it's not Java AWT or Swing. What on earth was Sun thinking when they designed that?
Give me raw Win32 over Xlib/Athena/Motif any day of the week.
I share your sentimental attitude, but looking at the past 10+ years of "post-native" desktop UI development being done in Electron, at al, it really does look like the days of platform-specific proprietary UI frameworks and toolkits are coming to an end. Modern HTML+CSS is a far more expressive medium for usable application UI layouts. Trying to build a "responsive" UI in VB6 is essentially impossible, for example. Even from a user's perspective I'm glad that fixed-size, DPI-unaware dialogs are done-away with.
I can't complain that much though - I don't miss writing low-level Win32 message-pumps - nor being limited by GDI's horribly outdated nature (fun-fact: it's impossible to build applications that support 10-bit color with GDI despite GDI's built-in support for different bpp values, because GDI assumed 24bpp / 8bpc was enough for anyone forever).
There's now only a few things missing from HTML+CSS that would enable true native-like applications: borderless sub-windows (think: for context-menus that can extend beyond the parent web-browser's client area on your desktop) and native macOS main-menu support (which feels like an anachronism given the large mouse-movements needed with today's humongous desktop display sizes).
I have spent 2014 - 2018 doing Forms/WPF GUIs for life sciences labs, and at least for those customers I can assure they aren't going to switch to Electron, more likely Qt or WinUI when time comes.
There is so much that the Web still fails short of WPF.
GPU support is not good enough in the browsers. Even 12 years old Direct3D 11.0 is way better than the current WebGL.
In WPF, it’s relatively easy to render a dynamic texture with Direct3D 11 or 12, then pass it to WPF to compose it into the GUI, without ever downloading pixels from VRAM.
Similar for compute shaders. You don’t need WPF to integrate DirectCompute, but you do need convenient native interop. These C structures, typed arrays and unmanaged pointers are all over the API surface. Not sure JavaScript is good enough for the job, the language and VM were designed for very different requirements.
A WPF app will load much faster and feel more integrated (more Windows like) than an electron app.
I have a C# / WPF app that I optimized to the best of my capacity but that still needs about 1 minute to compute data. I shudder to think how long JS would take to do the same job.
Let's unpack this...
> Not really sure why there was so much hate on swing
Swing itself isn't bad (compared to its predecessor in AWT) but Swing is still an abstraction over multiple different and incompatible desktop UI toolkits - therefore it has to compromise.
> probably from the people who never used it
Used it as an end-user, or used it as an applications developer, though?
The last time I used Swing was around 2010 - and I admit that I haven't stayed on-top of new developments, but I assume that Sun/Oracle switched emphasis away from Swing over to JavaFX (their WPF-compete) and that Swing hasn't changed much (at a fundamental level) much. Please correct me if I'm wrong.
> No performance issues
Yes-and-no. Things like repainting a busy charting component is fast enough, sure - but one thing about Swing that sticks out like a sore thumb is abysmally slow window repainting when a window is resized - I first noticed this when I was a lame warez kiddie using Limewire almost 20 years ago (wow...): actively resizing the Limewire window would cause the JVM to pause repainting the window and just draw a black background color until a few hundred milliseconds after I finished resizing. I've noticed similar behaviour in other Swing applications. It isn't pretty. Especially on macOS where users expect to be able to smoothly resize application windows.
> looked good enough
"good enough" is not exactly the best review in the world
> themeable
Yes, but who honestly goes through the effort to make an entire theme just for their own application? That's only affordable if you're a software giant or a company whose brand identity is heavily based on their software UX (and if that was the case, they wouldn't be using Java for desktop applications).
> I actually built apps that when compared with other native themed apps would not have been distinguishable from windows native
This may have been true in the final months of Windows 98/Me and Windows 2000, but Swing's inability to correctly reimplement (or even wrap) Windows XP's visual styles (especially the animated controls and when running outside of 96dpi mode) was exactly what gave Swing that uncanny-valley feeling (granted - and hypocritically - Microsoft's own WPF is also guilty of this, which is why I avoided it entirely until recently).
I haven't used Xamarin.Forms, what's the problem with it?
In any case, MAUI is Xamarin.Forms extended to the desktop, the name changed for marketing purposes.
Unless you’re prototyping or really don’t care at all about UX I don’t see why you wouldn’t write the UI in the native framework. And if you don’t care at all about UX then HTML+CSS+JS is probably a better choice.
Xamarin Forms let us build 4 years worth of tech for Android only. And then, when we had time and the customer demand to do so, with a small amount of work - port our app to 2 other platforms in fairly short order.
I don't know of any other platform that could do this - particularly when considering the years involved.
Our app uses local databases on the device - so a web based app would not have cut it. And our app has roots in 2014 tech when many possible alternate approaches did not exist yet.
https://devblogs.microsoft.com/dotnet/net-core-releases-and-...
Yes the team is small, still great than zero and more mature than plenty of wannabe FOSS GUI frameworks.