Mastodawn

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.

Michael van Niekerk 🦀 ☕️ ⚛Apr 12

@musicmatze Tauri + React Native Web; React Native + https://github.com/jhugman/uniffi-bindgen-react-native

= Reuse same Rust library
= share RN components for UI
= Target all desktops and mobiles

My go-to atm.

GitHub - jhugman/uniffi-bindgen-react-native: Make React-Native Turbo Modules out of Rust

Make React-Native Turbo Modules out of Rust. Contribute to jhugman/uniffi-bindgen-react-native development by creating an account on GitHub.

GitHub

@mvniekerk
Yeah but it uses React

Michael van Niekerk 🦀 ☕️ ⚛Apr 12

@musicmatze Nice thing is that it seems like LLMs are trained to a t on React / React Native. Making a Rust lib, LLM-ing a RN face on it is extremely fast.

Michael van Niekerk 🦀 ☕️ ⚛Apr 12

@musicmatze But yeah, if you're averse to React then stay away.

@mvniekerk
I am not averse to React, I just want to use Rust for the full stack because I am most proficient in Rust

Michael van Niekerk 🦀 ☕️ ⚛Apr 12

@musicmatze I've went the Leptos + Tauri route for a desktop app.

It was OK?

IDE support was rubbish, compile times extreme, build/target 60gb+.
At least the live compile reload did bring some productivity, but you still had to right+click refresh to reload the app and loose all state when doing so.

If React Native's dev experience is an 8 to a 9, Tuari+Leptos would be a 5 to a 6.
Let's call it "serviceable".

The Tauri+Dioxus route for me was not great. I had esp issues with sizing in that the view port was always too small so scroll bars in horizontal always happened, cutting off components and just giving terrible jank everywhere.

This was 1y ago. Maybe it has been fixed? Yeah...

@mvniekerk
Ok thank you for sharing that experiences!

Compiletimes do not matter that much to me, 60GB target sounds rather small 😜 at least to what I am used to.

Dioxus does not even work for me out of the box (e.g. https://github.com/DioxusLabs/dioxus/issues/5368) that's why I am exploring alternatives in the first place.

I have almost no experience with GUI app development, so I cannot compare experiences. Ah and IDE support ... Meh... As long as rust-analyzer works, I am fine. 😂

"file_explorer" example does not work · Issue #5368 · DioxusLabs/dioxus

Problem I am trying to get something working, but dioxus seems not to work at all for me: Steps To Reproduce Steps to reproduce the behavior: dx serve --desktop inside the file_explorer example Scr...

GitHub

@mvniekerk
Still: thanks for sharing 👍🙏

Michael van Niekerk 🦀 ☕️ ⚛Apr 12

@musicmatze On RustRover, at least it gives errors but has no way to fix them. Autocomplete inside the macros fail, but at least tells you what's failing at what line.

That's RustRover, I don't use VSCode+Rust analyzer.

Michael van Niekerk 🦀 ☕️ ⚛Apr 12

@musicmatze But all the best, hope you get joy out of it.

@mvniekerk thanks. That's mostly the goal (that's also why Rust-only 😉 )

@mvniekerk Neither do I.

Autocomplete does not work in macros because rust-analyzer cannot do that (not sure whether RustRover uses that under the hood, if not I would assume it does not work for the same reasons).

@musicmatze @mvniekerk fyi: rust-analyzer can do autocomplete in macros under some circumstances. It "just works" in macro_rules and afaik theres things you can do while writing a proc macro to make it work better.

@mvniekerk @musicmatze RustRover is quite a bit different than rust-analyzer, i would be careful to claim anything about IDE support from only tryin RustRover. rust-analyzer is part of the rust project, so it tends to be the tool projects are tested with. As a LSP, its also usable in many other places outside VSCode.

@laund @mvniekerk yep, I use neovim exclusively ... 😉

@musicmatze Nice! Sounds like an exciting project! 🤓

I'm currently building a GUI app in tauri, too (with a Vue frontend) and I'm really happy with it. My notebook from 2013 is struggling with comp times and RAM hungry rust-analyzer, but apart from that it's a very good DX.

(Funnily enough, I've started with a TUI, too, but wasn't the right fit).

Is your app going to talk to a web api and store data in a database (hence the need for axum)?

@janriemer
Not directly. My backend is developed with tower and exposing the app functionality via Services is natural because of this. Exposing the whole backend via axum to a Frontend just feels natural, because that makes the whole thing easily Frontend agnostic, so adding a TUI later on that same API base is a no-brainer.

@musicmatze Ah, got you, thanks!

Reason I'm asking: tauri itself has the concept of a backend and frontend:
https://tauri.app/develop/calling-rust/

So I assume your data flow might end up like the following:

leptos -> tauri backend (commands) -> axum backend

I'm looking forward to what you're building. Have fun!🙂

Calling Rust from the Frontend

The cross-platform app building toolkit

Tauri

@janriemer
Yes that will probably be the idea.

I am building a distributed social network.

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

tape occlusion mast [TudbuT]Apr 12

@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.

tape occlusion mast [TudbuT]Apr 12

@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.

tape occlusion mast [TudbuT]Apr 12

@laund @musicmatze

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

100%

@laund RE Requirements:well... it should be a normal desktop app. The backend code might be decoupled (a local service that the GUI connects to) at some point,... but that really is it.

I had a look at egui some time ago (maybe a year) and while I liked the idea, I think the whole webview thing is a more sustainable route. I also played with Slint and liked the general idea, but still ... the webview way feels better somehow. Also the licensing situation with slint is just ... not to my taste if I may say.

All of this is "for fun", so there's no business case behind this. So far, the webview stuff did not make me mad, so there's still "having fun" involved... I might resort to Slint or egui if I get frustrated (likely in this order), but I am not there yet 😆

@laund re requirements "normal desktop app"... so: notifications, filesystem access, networing, all that stuff ... that's what I mean by "normal desktop app"

@musicmatze yea, egui+eframe fulfills those criteria.

For sustainability: I doubt egui will go away. Its been around long enough and stayed roughly the same, at this point its used by quite a lot of projects, i'd rate it about as sustainable as ratatui.

Personally, i find the webview stuff extremely frustrating due to the long and storied (read as : filled with inane decisions nobody wanted to revert) history of web standards and the surprisingly large performance impact for what should be simple applications, but if you're having fun, go ahead. Its certainly not a rare choice.

as for slint: its never been in consideration for me due to the licensing, so yea, i get you on that

Chris Cochrun ~ >Apr 13

@musicmatze just gonna put this out there, and you don't have to even care one bit, but iced is really quite nice. I have been using system76's fork called libcosmic, been a great experience.

@chriscochrun yeah I have played with it already and found it quite nice!