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

@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 ๐Ÿ‘๐Ÿ™

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

@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 ... ๐Ÿ˜‰