5 ms·

I recently started to get an interest in writing a GUI with Rust. In particular, a database GUI. Initially, I thought Tauri with Svelte. Then I learned about g

I recently started to get an interest in writing a GUI with Rust. In particular, a database GUI. Initially, I thought Tauri with Svelte. Then I learned about gpui (https://www.gpui.rs/ https://www.gpui.rs/) and I'm intrigued. TIL about iced, which seems to have been around for a while. Before I embark on building a prototype UI for my app with all three libraries, does anyone have hands-on experience they can share?

airstrike 9mo ago
i'm building "Cursor for business users" with spreadsheets and documents in lieu of a code editor. I'm 90kloc in and couldn't be happier I encourage you to join the Discord and look around
jenadine 9mo ago
There is also Slint, if you want another option. https://slint.dev https://slint.dev
chironjit 9mo ago
I've built apps with Iced, Dioxus and PopOS's version of Iced. Here is my opinion: 1) Iced requires you to style everything in their own styling methods. It's not as intuitive as CSS. I found that, coming from using CSS, I struggled to recreate the style to the same high bar I expected from websites using css. 2)LLMs are not as familiar with Iced's styling, and will struggle with helping you plus also dealing with the breaking changes between Iced versions. Same to a lesser extent with Dioxus 3) Dioxus is easier to build by hand and via LLMs since you just use CSS/tailwind CSS. That said, even Dioxus is rough on the edges, you occassionly get some weird bugs, that you just have to deal with 4)PopOS' Iced version is great if you're using it on PopOS specifically but will require you to install a separate style pack on other linux distros to get the styling of the windows to show correctly. It's more mature than the original Iced IMO, though it's opinionated styling(of it's starter boilerplate) may be less to your liking. While I haven't used it in some time, I would consider it an almost independent fork by now 5) Last but most important negative IMO of Iced and Dioxus is their release cadence. Iced 0.14 has now launched more than a year since 0.13. For some the stability is great, but for frameworks that are still maturing with lots of improvements pending, I think it's actually important to have faster release cadences so that you know issues you face are not left hanging for a fix for a year. Now onto more practical stuff: 1) If you need simple, standalone apps, any one will work. I think this may be true for your app idea If you need speed of change, multi platform, etc, you will likely end up with Tauri. In that case, you might as well use the front-end framework you like. 2) None of the frameworks give you a pathway to publishing except Tauri. Basically, only Tauri really puts that as part of its guide, and so when you are going to Publish, you will be using Tauri's guide anyway 3) If you need multi-processing, Dioxus is out of your option, or you will end up using Tauri with Dioxus as your front-end
- mootoday 9mo ago
  Thank you, I appreciate the in-depth opinion! I think Tauri with SvelteKit is going to be my first prototype, likely followed by gpui because I'm impressed by Zed which is built with gpui. Also, TIL about PopOS, thank you!
  - chironjit 9mo ago
    Looking forward to trying out your app!
- airstrike 9mo ago
  you can use the iced master branch at any time to take advantage of the latest features. besides, new releases have nothing to do with fixing your specific issues. and the pop os fork has historically rebased to the latest upstream release so not sure why you think it's independent
  - Klonoar 9mo ago
    You do not know their specific issues, their wording isn’t stating what you seem to think. The master branch approach isn’t always ideal and people prefer having actual releases to base their work on. Not having a set release cadence and it more or less being on the whims of the one maintainer doesn’t exactly inspire the same level of trust you get from Dioxus/etc.
    - airstrike 9mo ago
      No issue at all is guaranteed to be fixed by the next release. There's no expectations that the deck of issues gets cleared when a new release is published, so conflating the two topics isn't accurate or helpful. You'll have to explain why the master branch approach isn't ideal. The only argument I've seen hold up is that the community can pin their own crates around a specific release, so if you rely on a lot of third party crates, you benefit from more frequent releases. Given iced is still pre-1.0, I do not encourage people to rely on a lot of third party crates. Most of them also have permissive MIT licenses so you can always bring any one-off bit of code into your own crate and maintain attribution. I did that with the split widget from iced_aw, which was available in 0.12 and dropped by those maintainers when 0.13 came around. I've since made several tweaks to it to fit my specific use cases, so all in all I'm just better off vendoring it myself. In fact, you also have no guarantee that third-party crates will (1) continue to update for future releases and (2) evolve their own APIs in the manner that you prefer. So if you're worried about being up-to-date and/or stability, again bringing the code into your crates is again the better choice—at the obvious cost of having to maintain it yourself, but such is the nature of software. I do not know what you mean by "inspire the same level of trust". Or I think I do, but I do not think it's helpful language or an accurate framing. Are you a part of the iced community? I can't speak for everyone, but ISTM that most everyone trusts hecrj implicitly—and we all understand iced is a labor of love, not commercial and the fact that it is subject to his whims actually helps guide a specific vision forward, however long that may take. The ride has been great so far. The Pop!_OS team seems to agree. Finally, about Dioxus specifically, I'll leave this informative video here https://www.youtube.com/watch?v=dKvFFf04clU https://www.youtube.com/watch?v=dKvFFf04clU

airstrike 9mo ago

i'm building "Cursor for business users" with spreadsheets and documents in lieu of a code editor. I'm 90kloc in and couldn't be happier I encourage you to join the Discord and look around

jenadine 9mo ago

There is also Slint, if you want another option. https://slint.dev https://slint.dev

chironjit 9mo ago

I've built apps with Iced, Dioxus and PopOS's version of Iced. Here is my opinion: 1) Iced requires you to style everything in their own styling methods. It's not as intuitive as CSS. I found that, coming from using CSS, I struggled to recreate the style to the same high bar I expected from websites using css. 2)LLMs are not as familiar with Iced's styling, and will struggle with helping you plus also dealing with the breaking changes between Iced versions. Same to a lesser extent with Dioxus 3) Dioxus is easier to build by hand and via LLMs since you just use CSS/tailwind CSS. That said, even Dioxus is rough on the edges, you occassionly get some weird bugs, that you just have to deal with 4)PopOS' Iced version is great if you're using it on PopOS specifically but will require you to install a separate style pack on other linux distros to get the styling of the windows to show correctly. It's more mature than the original Iced IMO, though it's opinionated styling(of it's starter boilerplate) may be less to your liking. While I haven't used it in some time, I would consider it an almost independent fork by now 5) Last but most important negative IMO of Iced and Dioxus is their release cadence. Iced 0.14 has now launched more than a year since 0.13. For some the stability is great, but for frameworks that are still maturing with lots of improvements pending, I think it's actually important to have faster release cadences so that you know issues you face are not left hanging for a fix for a year. Now onto more practical stuff: 1) If you need simple, standalone apps, any one will work. I think this may be true for your app idea If you need speed of change, multi platform, etc, you will likely end up with Tauri. In that case, you might as well use the front-end framework you like. 2) None of the frameworks give you a pathway to publishing except Tauri. Basically, only Tauri really puts that as part of its guide, and so when you are going to Publish, you will be using Tauri's guide anyway 3) If you need multi-processing, Dioxus is out of your option, or you will end up using Tauri with Dioxus as your front-end

mootoday 9mo ago
Thank you, I appreciate the in-depth opinion! I think Tauri with SvelteKit is going to be my first prototype, likely followed by gpui because I'm impressed by Zed which is built with gpui. Also, TIL about PopOS, thank you!
- chironjit 9mo ago
  Looking forward to trying out your app!
airstrike 9mo ago
you can use the iced master branch at any time to take advantage of the latest features. besides, new releases have nothing to do with fixing your specific issues. and the pop os fork has historically rebased to the latest upstream release so not sure why you think it's independent
- Klonoar 9mo ago
  You do not know their specific issues, their wording isn’t stating what you seem to think. The master branch approach isn’t always ideal and people prefer having actual releases to base their work on. Not having a set release cadence and it more or less being on the whims of the one maintainer doesn’t exactly inspire the same level of trust you get from Dioxus/etc.
  - airstrike 9mo ago
    No issue at all is guaranteed to be fixed by the next release. There's no expectations that the deck of issues gets cleared when a new release is published, so conflating the two topics isn't accurate or helpful. You'll have to explain why the master branch approach isn't ideal. The only argument I've seen hold up is that the community can pin their own crates around a specific release, so if you rely on a lot of third party crates, you benefit from more frequent releases. Given iced is still pre-1.0, I do not encourage people to rely on a lot of third party crates. Most of them also have permissive MIT licenses so you can always bring any one-off bit of code into your own crate and maintain attribution. I did that with the split widget from iced_aw, which was available in 0.12 and dropped by those maintainers when 0.13 came around. I've since made several tweaks to it to fit my specific use cases, so all in all I'm just better off vendoring it myself. In fact, you also have no guarantee that third-party crates will (1) continue to update for future releases and (2) evolve their own APIs in the manner that you prefer. So if you're worried about being up-to-date and/or stability, again bringing the code into your crates is again the better choice—at the obvious cost of having to maintain it yourself, but such is the nature of software. I do not know what you mean by "inspire the same level of trust". Or I think I do, but I do not think it's helpful language or an accurate framing. Are you a part of the iced community? I can't speak for everyone, but ISTM that most everyone trusts hecrj implicitly—and we all understand iced is a labor of love, not commercial and the fact that it is subject to his whims actually helps guide a specific vision forward, however long that may take. The ride has been great so far. The Pop!_OS team seems to agree. Finally, about Dioxus specifically, I'll leave this informative video here https://www.youtube.com/watch?v=dKvFFf04clU https://www.youtube.com/watch?v=dKvFFf04clU