The state of Rust GUI libraries

[alexzeitler]

https://blog.logrocket.com/state-rust-gui-libraries/

[_nalply]

> Thanks to its web-based architecture, Tauri applications are lightweight and fast. Tauri runs on web technologies, and apps run smoothly on low-end hardware.

My opinion: Tauri is useful but being web-based some of Electron's problems apply. Especially I wouldn't call it leightweight and fast and I don't think that a webview would run smoothly on low-end hardware.

It really seems this article has to be dismissed as a honeypot for search engines like Google or Bing I am afraid. After some thinking why: LogRocket is a for-profit organisation after all. They have products for monitoring apps. To sell they need leads.

So we have a case of misaligned incentives: The usefulness or factual correctness is not the ultimative motive, but success of business. Whatever.

[rcarmo]

None of these seem to be truly “native” in the sense that the use the native platform’s UI widgets. Is “repackaged web” the new native?

[yencabulator → rcarmo]

GTK and FLTK are web now?

(Of course, they aren't really Rust, just bindings to C libraries.)

egui goes straight to graphics APIs, but it's not really a desktop UI widgets kind of a thing, more a game-oriented custom UI builder.

Iced has pluggable rendering backends, but I understand it also targets the low-level graphics APIs directly.

[rcarmo → yencabulator]

FLTK was hidden away in there, yes. Most of the article seems to be fluff, though, so the mis-characterization is rampant.

[sliken → rcarmo]

Rust's native support of WebAssembly makes sense that a common default is use a browser based UI.