web-to-desktop-framework-compariso VS Windows UI Library

Seems pretty sensible!

I always wonder how those established Electron codebases would map over to something that uses the system specific WebViews and how broken (or not) those would prove to be:

https://wails.io

https://tauri.app

But admittedly that would just decrease the bundle size while doing not much for the performance or resource usage: https://github.com/Elanis/web-to-desktop-framework-compariso... so maybe not super relevant to this particular discussion.

My current project uses Wails and a previous one used Tauri. I like Tauri a bit more but not enough to justify porting Go code to Rust. The primary difference I run into is how the JS <-> native interface is exposed, but this is very minor.

Tauri is much slower to build, I think this is just the nature of Rust though. Stats here. [1]

1. https://github.com/Elanis/web-to-desktop-framework-compariso...

https://github.com/Elanis/web-to-desktop-framework-compariso...

Electron comes out looking impressive at runtime!

Memory Usage - (Average of runs) Median of difference between system measured free memory before execution and during execution)

> it's still a far cry from your ~200 Mb Electron hello world.

I think that projects that ship packaged web apps but attempt to use the system native web views where available are really nice, like Wails: https://wails.io/ (so for example, on Windows it would use Webview2, so you don't have to package an entire Chromium install yourself)

Here's a comparison of how the distribution sizes change, Wails in particular also has way faster builds than something like Tauri: https://github.com/Elanis/web-to-desktop-framework-compariso...

That said, I wish we got more native software, or even something like LCL that can target Win32, GTK, Qt or whatever else is available. Sure, writing components that are available on a lot of platforms and work similarly everywhere is a pain for the developers, but I applaud the effort regardless, since the above solutions like Wails don't actually do anything for the memory usage and CPU cycles, whereas native GUI software is better for most apps that don't try to be very interactive.

I mean, most OSes already ship with a WebView component that you can use instead of shipping an entire browser runtime.

Wails does that: https://wails.io/

Tauri also does that: https://tauri.app/

That does help with the needed resources quite a bit: https://github.com/Elanis/web-to-desktop-framework-compariso...

Sadly it doesn’t change the memory usage much so the technology is still inherently wasteful, but on a certain level it feels like a lost battle - because web technologies often feel like the choice of least resistance when you want GUI software that will run on a bunch of platforms while not being annoying to develop (from the perspective of your run of the mill dev).

I looked into some alternatives a while back [1] and thought Neutralino looked promising except that it doesn't support node modules. I.e. you cannot use the existing ecosystem of node-stuff.

Still, glad there are many options for using web UI to create desktop apps these days.

[1]: Neutralino themselves link to this nice comparison table: https://github.com/Elanis/web-to-desktop-framework-compariso...

> but it uses your system's existing browser

According to (1) that is incorrect. It uses WebKitGTK+.

(1) https://github.com/Elanis/web-to-desktop-framework-compariso...

This comment should provide a good overview of the current chaos,

https://news.ycombinator.com/item?id=40843252

Then check the feedback on the latest community call,

https://github.com/microsoft/microsoft-ui-xaml/discussions/1...

Anything related to WinUI is a bad joke.

Have fun following the discussions and amount of bugs,

https://github.com/microsoft/microsoft-ui-xaml

That C++ support that WinUI team marketing keeps talking about relies on a framework that is no longer being developed.

> The reason the issues page only lets you create a bug report is because cppwinrt is in maintenance mode and no longer receiving new feature work. cppwinrt serves an important and specific role, but further feature development risks destabilizing the project. Additional helpers are regularly contributed to complimentary projects such as https://github.com/microsoft/wil/.

From https://github.com/microsoft/cppwinrt/issues/1289#issuecomme...

DevExpress supported WinUI for a little while but decided to abandon support.

One of the biggest problems with WinUI compared to WPF is that DependencyProroperty is implemented as native code, so for .NET developers, there is a huge performance penalty getting or setting any property on control.

https://github.com/microsoft/microsoft-ui-xaml/issues/1633#i...

Visual Studio's designer really does not support WinUI 3. Try it! Hot reload also doesn't work worth anything. There's an ongoing issue/discussion on Github here [1] from 2021. There's also loads of fundamental issues like various controls causing replicable crashes with drag and drop, the community calls are disappearing, and more.

[1] - https://github.com/microsoft/microsoft-ui-xaml/issues/5917

It suffers from young developes wanting to ship Chrome alongside each application.

And it doesn't help that UWP and C++/WinRT turned out such mess that even their own teams rather use Webviews than native UIs.

https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...

https://blogs.windows.com/windowsdeveloper/2024/06/03/micros...

https://github.com/microsoft/microsoft-ui-xaml/discussions/9...