Correct me if I'm wrong, but isn't the problem with tauri and wails that they are still dependent on the client's native OS webview? I know Tauri uses WRY which essentially takes in your request, finds the webview present in the client and calls a corresponding function. The differences between these webviews are vast and you end up with different UIs or cobbled together adjustments for each OS to split the differences. Fully embedding a browser is extremely storage inefficient but it does guarantee apps look identical regardless of platform.

Depends on what you care more about: the package size or that sort of consistency in exactly how things look. For example, when I was using Wails to quickly throw together a UI for managing some other client software, small package sizes were great and since whatever I do inside of a WebView/browser will always be different than the native OS GUI solutions, slight differences were inconsequential. Someone else might have vastly different requirements.

> consistency in exactly how things look

It's not just how things look, though, there are a ton of differences between browsers in terms of how things behave, too.

More different than the normal differences webdevs need to handle, safari vs chrome vs firefox vs edge?

No, less, since it's really only two:

- Blink for Windows/Qt hosts.

- WebKit for macOS/GTK hosts.

I remember when web developers actually gave a damn. Just call yourselves Chrome developers because that's what you are now.

> The differences between these webviews are vast and you end up with different UIs or cobbled together adjustments for each OS to split the differences.

Like frontend developers do all the time? Why would this be an issue for apps but not on web? Reminds me of the old ”our website works best in Internet Explorer” banners.

The webviews on windows, Linux (gtk) macOS, iOS, Android all support modern CSS and are basically identical. Speaking from experience.

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

Interesting resource, thanks!

Was not expecting the start up values for Tauri, they're abysmal ._. Welp, at least the executables are small.

Tauri uses the native webview on the platform, which is presumably why startup values are all over the place. (It's also somewhat suspect to the point of warranting investigation; even using the native webview there seems no reason for something that takes half a second on Windows to take 25 seconds on Linux).

I had this same observation. My guess is because Tauri uses WebGtk and Linux doesn’t really have a “native webview” so it’s kinda shipping the whole thing? The startup time seems like Tauri’s a non-starter for a lot of apps if you want them to be cross platform, had no idea this was a thing.

These startup times do not make any sense. I've developed a little toy app using Tauri+React and it starts pretty much "instantly" in all platforms.

For me Tauri/Wry starts up pretty instantaneous. This is using Wry as the renderer for the DomTerm terminal emulator (https://domterm.org), invoked with 'domterm -Bwry'. This is on Fedora Linux 41 x64. Admittedly using a rather old version of Wry (0.43.1) with webkitgtk 2.46.5 - I haven't had time to update.

I recently build a torrent streaming app on tauri (lemontv.xyz), it is just amazing framework, it is damn fast on every platform. The only issue is that accesing system api's a bit problematic especially on android side...I needed to get into JNI calls to run a background thread on android so that when the user puts the app on foreground, the app needs to do a bit more of buffering. I mean in general, Tauri is or could be one of the best options if you are writing rust backend and have cross platform requirements.