So I have read some more about the whole #dioxus vs #tauri plus #leptos plus #axum for a #rust #rustlang #desktop app.

From what I read by now, I would say that I will try the tauri route next. I would still prefer if Dioxus would just work, but what makes me wary about whether Dioxus would be a sustainable choice is that there's a lot of issues in the Dioxus repository that do not even have a reply by a maintainer. My own issues (which are relatively young!) have only little interaction. I get that this is an open source project and maintainer overload and so on, sure. But there's also something about Dioxus being funded? So there are full-time devs (plural!) working on it? What can I say? This makes me wary.

Going down that tauri route would mean that I would need to build the whole thing myself. That could work, but is more than I would have liked to do. I want to develop my app functionality, not set up a GUI development environment.

I could also go for a TUI first, but tbh, I would rather like to have a GUI first, with a clean API that I can then reuse to build a TUI on top of it. Not sure why, the other way around would probably work as well 🤔.

Either way, I would then try leptos as framework for the app, because it looks rather good from what I can read from its documentation, and I can use axum in the backend, which I think fits my needs as well. (Btw developing this with ratatui with a axum backend would also be possible, but that's not the "native way" for a ratatui app, but much more for a leptos app as I understand it, so I expect less headaches here).

I hope I can get a MVP fast, so I can get back to developing my core application stuff, because there's sooo much missing still.

@musicmatze

What do you need from the desktop app, requirements wise? Since you mentioned even considering a TUI app, i might have some ideas:

  • egui.rs is probably the easiest to use UI framework for Rust. with eframe you can make desktop and web apps in it. Probably the fastest to build a MVP.
  • bevys UI framework is slooowly getting there. Its still far from ideal out of the box, but theres quite a few community plugins to improve it and its pretty flexible. if your project could benefit from 3d or 2d rendering at all, it may be worth a try. Plus: really active maintainers.

those are the ones i can "recommend" (ehh, more point out as options) as i've used them myself

@laund @musicmatze i can definitely say egui is great for quick stuff, but ive honestly given up on rust gui recently since its either a dependency nightmare or doesnt work. there seems to be a new library called ply that is neither by some definitions but it still has issues (e.g. sharpness for some reason) and is at least partly vibe coded.
@laund @musicmatze point is, youll probably have the best experience with egui, but itll mean your app will take ages to compile

@tudbut

I haven't noticed much difference between a bevy project with or without egui, but thats probably a combination of: bevy is already large (tho mitigageted by their dynamic linking feature), my default ~/.cargo/config.toml has a lot of compile-speed optimizations applied, and i own a pretty beefy CPU.

for @musicmatze reading this: the "dependency nightmare" out ouf tudbuts mouth is a very... relative term. I've had long discussions with her about acceptable dependency amounts, and safe to say her standards are way more strict on having as few as possible than most peoples. If Tauri, Leptos, and Dioxus were/are in consideration, egui is not gonna fail due to the dependency count.

@laund @musicmatze

If Tauri, Leptos, and Dioxus were/are in consideration, egui is not gonna fail due to the dependency count.

100%