Older stuff is generally faster because it had to be built in a more resource poor time. Maybe the WinUI devs should be forced to work on systems with the Minimum System Requirements. Heck, maybe all Microsoft development should be done like that, so that some focus on performance is there from the start, instead of as an afterthought.
Both had huge issues UX wise, specially desktop, but performance and stability was never a issue.
Developers should always test their system on the minimum system requirement that they allow the system to be installed...
I remember I complained about WinUI performance years ago, and they told me at the time that "performance" was not the focus...
I'll never forget the Asus Netbook proudly boasting about its 1024MB of memory via a colorful sticker that'd be considered excessively large on a 17.3" workstation, somehow running Gimp with multiple layers on Windows 8 alongside a few Chrome tabs without a care in the world. UX of 8 and 8.1 was awful, but it was optimized and stable in ways that made me hopeful for what MSFT would deliver in the future. 1gig of memory, a spinning hard drive and a single low powered x86 core were enough to get some image editing for a then school course done with some wiki pages in the background. I'd hardly believe it, had I not lived it. 10 and 11 have been regressions in my book.
The UX of Windows 8 was amazing on tablets, to the point where it's still my favourite touchscreen UI. The keyboard+mouse UX wasn't very good though, which is all that >99% of users ever used.
> 1gig of memory, a spinning hard drive and a single low powered x86 core were enough to get some image editing for a then school course done with some wiki pages in the background. I'd hardly believe it, had I not lived it. 10 and 11 have been regressions in my book.
I had a similar experience with the earlier releases of Windows 10 also [0]. I'm not really sure when Windows's performance got worse, but it was definitely some time after that.
WinRT is the Windows team final response to Longhorn, but lets do it with COM and C++, which started in Vista.
This is why all major new APIs since Vista are COM based.
So you get an UI framework with reference counting all over the place, and application identity, which is a kind of sandboxing, for the capabilities like in mobile OSes or macOS.
On the UWP subsystem, you get .NET Native and C++/CX, whose runtimes are WinRT aware and can elide those RC calls.
Whereas using WinRT on Win32, means regular .NET and C++, via interop frameworks CsWinRT and C++/WinRT, plain libraries.
So there is no elision, it is AddRef/Release all over the place.
Reference counting is a virtual function call + an integer operation. It doesn't happen that often either because objects in UI frameworks are very long lived. C++'s shared_ptr, Rust's Rc, and Swift, don't typically cause performance problems either.
I can also easily point you on CppCon, C++Now and WWDC talks, where presenters spend valuable time of their lifes speaking about matters you don't believe.
Not sure what you mean, I was using COM and C++ for Windows development in the late 90s.
> So there is no elision, it is AddRef/Release all over the place.
...and constructing an object is an insanely complex (and expensive) operation.
After Longhorn's failure, Windows team vouched to replicate all the .NET based ideas for Longhorn, as COM in Vista, followed by the Hilo code sample in Windows 7, how modern Windows applications should look like.
https://learn.microsoft.com/en-us/previous-versions/msdn10/f...
Best quote from Hilo, to show how Windows team sees .NET,
> So overall C++ is a good choice for writing Windows 7-based applications. It has the correct balance of the raw power and flexibility of C, and the sophisticated language features of C#. C++ as a compiled language produces executable code that is as close to the Windows API as is possible and, indeed, the C++ compiler optimizer will make the code as efficient as possible. The C++ compiler has many of options to allow the developer to choose the best optimization, and Microsoft’s C++ compiler is one the best ways to produce small, fast code. WinRT was the next step, coming back to the ideas that predated .NET as the COM evolution, before Microsoft got distracted with J++ and the project pivoted.
https://arstechnica.com/features/2012/10/windows-8-and-winrt...
https://web.archive.org/web/20190111203733/https://blogs.msd...
This might be off topic, but wish Apple would focused on Finder performance (app loading, window refresh, etc) like this blog post by Microsoft.
And in case you're curious, my disk is only using 250GB in use (50GB for Apps, 150GB for System Data, 50GB for macOS)
No one dog-fooded that thing.
I open Finder, click on Applications, search "Google Chrome". Top results? MarketingAnalytics.yaml, aria-proptypes.md, and so on, from some project I cloned off of Github into my home directory at some point. I guess the file contents include "Google Chrome"?
Clearly insane, but under the "Advanced" finder settings, it's easy to find "Search the Current Folder". Suddenly, you get the result you'd expect.
Hope there's a day I can just use Dolphin on any system
I booted up an OLD imac stuck on 10.something, with an - I can't remember which gen - i5 and only 8gb of ram and I was blown away by how much it FLIES on that ancient hardware - even compared to my M1 Max Mac Studio
Apple Silicon is great. Everything else sucks.
And if you don't agree, this is Windows we're talking about. Nothing's stopping you from creating your application with Win32 except for the fact that it's going to look and feel like an application from 20+ years ago.
This is funny. You know, users also want games to be ridden of DRM but I don’t think the big companies cared about that for a long time. Users also want a lot of things that they never got, like a visible scroll bar sometimes.
And since Windows is primarily OEM or enterprise, I don’t know what users are going to do if Microsoft sticks to say Windows 7 UI? Like, uninstalling Windows and switching to Linux? Oh yeah, they are doing that right now.
Sure users want A or B, but that’s not important. What’s important is some idiot VP saw something and decided to push on, and other managers jumped in to grab the pie.
This is not a rhetorical question. I do see some things, like antialiased drawing, etc (GDI is outdated, but I'm not convinced newer drawing could not be added.) But in general the classic ones work, including with accessibility, and are highly functional and batle-tested.
.. and get much less. Especially in accessibility. We've lost things like ubiquitous accelerator keys and even basics like "being able to tell where the edges of controls are or which is the active window".
The only real advantage WinUI has over WinForms is "responsive" resizing and display scaling.
I think another way to get to the same effect is to say “A company needs good leaders”.
I also wish that they’d make WinUI work on macOS as well similar to Avalonia, but I think they probably won’t.
Is there any reason I would use this over something cross-platform like EGUI? I am kind of over software being OS-specific; this is one of the biggest compatibility mistakes we've made. Along with the related process of making drawing pixels on a display a complicated process!
But it's been long gone that time where Windows had a minimum cohesive guideline.
At my day job, I choose Windows Forms with Blazor mixed in. That's old reliable Win32 tech + modern web tech, without any modern Windows tech mixed in.
I wish Microsoft just sticked to Win32 instead of reinventing the wheel with worse solutions.
> If you want a GUI that looks native, egui is not for you. If you want something that doesn't break when you upgrade it, egui isn't for you (yet).
With egui, it's an immediate mode GUI rather than retained mode and that has trade-offs: https://github.com/emilk/egui#why-immediate-mode. It's going to use more CPU (and battery power), there can be jitter and things shifting after the initial rendering, and other stuff. I think egui is very different from most cross-platform and platform-specific libraries.
With .NET MAUI, you're getting native controls, but you're now using a layer that's trying to use native controls on the underlying systems that don't always align completely. A lot of things act mostly the same across systems, but some things don't totally.
With Flutter, your app is going to be larger in part because you're shipping a rendering engine, runtime, widgets, etc. Does it have the look and feel you want? Maybe. That's a bit subjective. Does it handle all the little things correctly? When I'm using an app, I want it to scroll like how I'm used to scrolling working on my system. If you have differently styled buttons, I don't care, but if the scrolling feels wrong, it's going to annoy me. And there's so many little things.
Frankly, one of the reasons why Electron often does well is that a lot of the little things "feel right" because the UI is essentially a Chromium-rendered web page which users are used to interacting with. But that has downsides too - shipping a web browser with your app and the memory usage.
Heck, Qt apps in Gnome or GTK+ apps in KDE can look/feel "off".
And it'll all depend on your ecosystem. Often cross-platform solutions are lacking in accessibility - sometimes completely missing, sometimes half-baked and it works in some parts and not in others or just is janky. Memory usage is often higher. Many little things that make an app feel right might not be there. Many have slower startup times since they're loading a bunch of stuff that native apps don't need to. And it really depends on what approach the cross-platform library is taking to determine what is going to cause pain.
So you kinda have to pick your poison and what's acceptable to you will vary depending on your goals and tastes. Maybe React Native is the way to go for you with lots of native controls available and the feel that provides and the performance and size is acceptable.
If you create a Flutter or Kotlin Compose Multiplatform or AvaloniaUI app and put it on the web, it's not going to feel right as something like HN does. Right-click, text selection, etc. are all going to be different or missing. If you're creating a solitaire game, maybe that doesn't matter - you get desktop and web in one go and it's not a big deal.
But you have to know what you're building to know if the trade-offs being made are good ones. This isn't meant to sound anti-cross-platform, but as someone who has suffered some pain in this area, I guess I just wanted to impart that it isn't all sunshine and rainbows. Some times it can still be worth it, but just go in with your eyes open.
But it is used to implement various parts of Windows, such as the File Explorer, so any improvements are helpful for general system performance.
Also seeing stuff like text fields re-implemented from scratch in XML scares me. I don't like to see that.
It was like Delphi and C++ Builder kind of experience, then they killed the whole experience.
Rust with windows-rs is hardly any better, and coming from the same folks that killed C++/CX, with false promises at CppCon 2017, I don't have great hopes for it. They will jump ship again after a new shiny.
Well, until they killed the designer for WinUI 3.0, yet another flaw they don't talk about.
At least still around for Forms, WPF.
Did you not read the thread? That's literally stated as an explicit goal.
With WinRT on top of Win32, the .NET Native runtime support now lives in CsWinRT, where they also only have C# into account, not even VB as it used to be on UWP side.
98: great. ME: bad. XP: great. Vista: bad. 7: great. 8: bad. 10: great. 11: bad
I recall it being pretty mediocre at release, just a reskinned 8.1. 10 started to come into its own much later after NT10
I'd love to know the exec who ordered Windows 11. It stinks of "I need a product on my resume that I launched because being Windows 10 "maintainer" sounds so pathetic on a resume."
I still remain naively hopeful and cheer them on, however.
Why not Avalonia? It's not Microsoft but it is a spiritual successor to WPF, cross-platform, and open source.
The only people that still buy into this are folks that never developed anything with WinUI, aka WinUI 3.0.
Since Windows 8, they messed up the development experience so bad, that they managed to turn many advocates like myself into vocal critics.
We avoid anything WinRT unless there is no way to do the same with Win32, classical COM (WinRT is an evolution of COM), or regular .NET (Forms/WPF).
And also post regularly about the actual state of the tooling unlike Microsoft's marketing posts.
Example, they keep mentioning about WinUI being supported in C++, but never mention how bad C++/WinRT dev experience has become, or that the framework is in maintenance, and has been superseded by WIL.