I think the Rust community is sleeping on the potential of iced for traditional desktop gui. I monitor the gui space in Rust closely and have seen many toolkits come and go. In my opinion a desktop gui library/framework needs to solve two things to be useful: architecture and advanced widgets.
egui has served me well and is eagerly recommended in "what gui should I use" threads since it solves the widget problem well in an easy-to-use package. However, any sufficiently advanced application ends up needing a nice architecture to maintain development speed and enjoyment. I've found whether using egui/slint/fltk/etc. you end up having to roll your own system. When you start needing things like undo/redo you suspiciously start architecting something that smells like the elm architecture.
Iced is the only Rust toolkit that I track that solves the architecture part upfront. The message pattern is hugely powerful but it is hard to appreciate until you've really gotten in the weeds on larger applications. Once iced reaches a point where there is an advanced set of widgets available I suspect its popularity will rise accordingly.
As a comparison, one of the most successful desktop gui toolkit of all times (Qt Widgets) solved the architecture/widget duality long ago with the signal/slot system and advanced widgets like treeviews, datagrid, etc. Since then we must have had hundreds of "desktop" toolkits across all languages that can draw buttons and dropdowns but nobody has toppled the king yet for building advanced desktop GUIs (although there were a few close competitors in C# with WPF and Java with Swing they only solved the widget part in my opinion). I like to think iced can take this mantle one day, best of luck to them and congrats on the 0.14 release.
It feels a little cringe how Elm and the "Elm way of thinking" is so heavily emphasised, but after using Iced, IMO this is probably one of the best gui models without having to implement signals or message passing or IPCs like Dioxus/Tauri does with frontend/backend. Other key advantages Iced has includes daemon mode, native ability to use multi threading and also multi-window support
That said, for actually building most apps, what's more important is likely ease of learning and using the framework, platform/OS support, publishing support, etc, none of which Iced itself directly address.
Alternatively, Flutter desktop with flutter_rust_bridge works great. Sure, not fully Rust, but Flutter has way more packages on the GUI side than, I'd say, all of the Rust GUIs combined, simply due to how much older it is.
> When you start needing things like undo/redo you suspiciously start architecting something that smells like the elm architecture.
Well Iced itself claims to be inspired by the Elm Arch, so that checks out (see the first line under the Overview section of the Readme https://github.com/iced-rs/iced )
I've got a stagnating Python Qt app prototype that I need to actually write properly. It's a personal project so I can do that without affecting users. I need to decide between Rust and Iced or stick with Python and Qt.
Python has a VLC library that embeds VLC behind the scenes for audio playback, and Qt had facility to work with it. This is terrific as I need to support a wide variety of codecs (voice recordings) and I need to change playback speed during playback. Does Rust or Iced have such capability to embed VLC? Not the VLC UI elements, just to use VLC behind the scenes.
Iced is a wonderful dead-simple framework. I hope it forever maintains the simplicity which combines nicely with Rust’s features.
One thing I love about Iced and miss in Qt is writing the software in a single language. Qt has chosen to introduce multiple languages into their framework which makes the entire codebase a huge learning curve. In Qt you write your display layer in QML then your UI logic in Javascript and any backend advanced logic in C++. It is frankly exhausting.
In Iced you write in Rust and use Cargo packages. This gives the developer ultimate composability and clarity of their application as well as powerful tools from an established ecosystem. If Qt wanted to provide a powerful Qml tool, they have to write it and build all of the IDE integration.
For the record Qt used to be moving in a pure C++ direction but that changed when Qml came onto the scene.
I actually love that separation. QML is a great language for writing beautiful, responsive, modern UI with animations easily. C++ is great for performance and logic. I don't like Javascript but I don't need to write a whole lot of it. I wrote my note-taking app's block editor in QML and C++ if some people are curious[1].
Yeah, I appreciate the separation as well actually, even though I'm not a fan of the langauges involved (no issue with QML, dislike JS and C++). I've made a few things with Qt and despite my feelings on the languages, found it to be pretty useful and capable, and the learning curve wasn't that bad imo. I can't recall using much JS to be honest, but it's been a hot minute since I worked with that.
That said there's simplicity to Iced being pure rust managed through cargo that I enjoy. Though it should be said that my "learning curve" for Iced was much lower than it might be for others as I discovered it well after I'd adopted Elm (which inspired Iced) and - independently - Rust, so Iced was pretty easy for me to grok.
I don't think there's a right/wrong way there to be honest, both approaches have their pro's/con's, and my main issues with Iced vs Qt is largely a matter of maturity/prevalence than any specifics with the implementations/workflow themselves.
I gave Notes/Plume a try a year or so ago, it was an interesting experience. I ended up falling back to Joplin as I could use it on macOS, iOS, and Fedora with synchronization via Dropbox.
I've always been curious about productizing apps like these, from a financial/business perspective have you found Daino worthwhile or enough of a success (by your standards) to continue developing it as a proprietary application?
Hi! That put a smile on my face (: I'm working now on a mobile version with real-time sync, so maybe give it another try when it comes out.
Not really, not yet. Once my FOSS app was popular I used to earn a livable amount of money from ads on the website. But after a SEO crash that all went down the drain and the money I'm getting now from subscriptions to Daino Notes is nice but not livable. I've been working the last year (at a really awesome place) doing React programming (my first salary job, actually) and at nights and weekends working on Daino.
I actually got many requests to license Daino Notes' block editor. So I've figured there's a business there. I'm working on something I'm calling Daino Qt which is a collection of different components to accelerate Qt apps development (so I'm also its client). It will include my block editor, components for mobile - current Qt components on mobile are extremly shitty - so I'm planning on changing that with things like native-feeling swipeable stack view, native-feeling text editing, etc. And maybe Qt C++ client SDK for InstantDB (and more stuff).
Hope I can sell this as well while also consuming these components for Daino Notes and other apps I will develop.
Yes, my FOSS note-taking app[1] used to be pure Qt Widgets. Recently, I've added the Kanban feature that uses QML (this and the editor settings should be the only parts in QML, if I remember correctly).
Haven't used Qt for a few years, but back then QML, QtQuick, etc have been optional features. You absolutely could write all your Qt logic in C++ only, in a somewhat similar way like the code shown in the iced READMEs. It is the same in any other classic GUI toolkit such as GTK+.
Biggest drawback in qt/c++ used to be the MOC. I guess they still have not gone rid of it, haven't they?
I did some Qt programming in Python (PySide6), but ran into segfaults, which should of course not happen no matter what you do in a scripting language (except when using modules like ctypes). Many of these cases were related to object lifetime handling which is difficult to do correctly in Qt, and many people have written about it. In Python (a garbage-collected language) one should not have to worry about this.
The last iced release was September 2024, more than a year ago. I imagine they had constraints that made it impossible to wait for upstream patches to be merged (if at all) and it was simply more tenable to fork and worry about merging later.
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
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.
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.
>The master branch approach isn’t always ideal and people prefer having actual releases to base their work on.
I think this is me. My view is basically like this - if you use a tech you know works, you're only wrangling with your bugs. If you use a tech that is still being worked on, you are wrangling your bugs and the bugs of the tech you're using.
To be fair, I've tried this master branch thing with both Iced and PopOS's Iced fork. One year ago, PopOs's Iced fork was so slow I realised it basically wasn't going to be production ready for non Pop distros anytime soon.
IMO, both suffer from having very slow release cadence but at least dioxus has CSS
I appreciate the thoughtful replies. I struggle to understand why CSS is such a big deal if you're not building for the web. I can make my app as pretty as I'd like using styling that isn't CSS. OK, maybe I miss glow effects, some nicer gradients and 3D transforms, but those are far from showstoppers and still worth giving up for everything else I gain with iced
You bet! Shadcn is defacto component framework for a reason - it removes a lot of the mental load of design when you're an individual/small team building apps
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.
I watched this video when it first came out. Honestly, the video is right in what it was trying to say. That said, that video didn't change my mind on whether to build on Dioxus and it should not for someone either.
The choice of framework should not be dependent on who else is building on that framework. Ideally the factors that matter:
1) Why are you building a GUI app on rust?
2) Target platform/OS support?
3) Are you ok with custom styling methods? Would you prefer to use CSS?
4) Need for multi threading?
5) Publishing / bundling / signing app
I think the reason Dioxus cadence release is slow is that they realised so many things are missing with the rust gui ecosystem that they decided they needed to fix these while building the main product. Guess what, this basically slows down your main product cadence. Does rust need a sub second hot reloader? Yes. Does rust need a native html/CSS renderer? Also probably yes. Did the Dioxus team have to take it on given their size and all the things pending in building rust with html + css? Armchair observer me thinks not.
*Note that I am currently building an app with Dioxus, so I'm putting out my honest opinion, and not saying that you shouldn't use it.*
I use Halloy, one of the applications featured in the readme, on the regular. It's great and the UI is very pleasant. I don't enjoy writing rust and very much wish someone would port iced to other languages.
Or poor keybinding support (though in the case of iced I see it's somewhat improved in this release with some IME support and non-latin https://github.com/iced-rs/iced/pull/3134, so don't know exactly what's left broken)
The there are non-runtime issues like lack of documentation
My iced apps startup much faster than the Qt(Pyside) and Electron apps they replaced, and run faster too. Similarly, memory usage is much lower, and shipping a single 25MB binary to customers is preferable to bundling some multi-GB runtime environment. So in practice I'm glad development focuses more on completing the framework before playing performance metric golf, even if minimizing startup time and memory usage would be nice.
The 'lack' of documentation was only a problem for me when I was doing a cursory comparison of UI frameworks. Once I seriously started learning iced, the resources available, including the community on discord, was plenty to start being productive on making real apps within a week or two (and I had very limited Rust experience before that).
What are the exact timings? And what OS? For a Windows example, a proper native framework would be fractions of a second, Electron would be many seconds (especially on first run), iced would be a few seconds (as also noted in the issue linked), but that's still way closer to the Electron range, not the "instant" native feel.
Runtime speed is something different, even Electron is not that bad since the UIs are mostly too primitive to cause much of a visible slowdown, here the styling/animation capabilities are usually more prominent.
> including the community on discord
that's not a good baseline to cover the basics due to variable latency and predictability.
200-300ms on Windows 11, with ~70MB of idle RAM usage.
> that's not a good baseline to cover the basics
I wasn't suggesting that everyone should join the discord and ask how to write 'Hello World'. There's an official (but WIP) book, unofficial guides, and many examples spanning basic to advanced usage for reference. An active discord is complementary to those. Having more learning resources is important for wide adoption, but that's not the priority in pre-1.0 development.
> startup much faster than the Qt(Pyside) and Electron apps they replaced, and run faster too
I forgot to mention, the iced apps have taken less time to develop more features with fewer bugs (and no segfaults).
Strange, checked the latest version of a counter app, same slow startup ~2sec as before and ~70M ram vs a native simple window app that takes 0.2s and 1M.
When I switch to compiling with just the tiny-skia software renderer, the counter app is reduced to a 4MB binary that starts in 60ms (for first paint, 16ms for window creation) and takes 7M of RAM. So if you don't need GPU acceleration that may be more to your liking.
First, the issue is not a closed=solved issue, if you bothered to actually read it you'd realize there is another currently still opened issue about this,
Second, there are no "issues", there is only one such link
I encourage you to read better next time and not close your eyes so tight as to miss the feedback.
I think the Rust community is sleeping on the potential of iced for traditional desktop gui. I monitor the gui space in Rust closely and have seen many toolkits come and go. In my opinion a desktop gui library/framework needs to solve two things to be useful: architecture and advanced widgets.
egui has served me well and is eagerly recommended in "what gui should I use" threads since it solves the widget problem well in an easy-to-use package. However, any sufficiently advanced application ends up needing a nice architecture to maintain development speed and enjoyment. I've found whether using egui/slint/fltk/etc. you end up having to roll your own system. When you start needing things like undo/redo you suspiciously start architecting something that smells like the elm architecture.
Iced is the only Rust toolkit that I track that solves the architecture part upfront. The message pattern is hugely powerful but it is hard to appreciate until you've really gotten in the weeds on larger applications. Once iced reaches a point where there is an advanced set of widgets available I suspect its popularity will rise accordingly.
As a comparison, one of the most successful desktop gui toolkit of all times (Qt Widgets) solved the architecture/widget duality long ago with the signal/slot system and advanced widgets like treeviews, datagrid, etc. Since then we must have had hundreds of "desktop" toolkits across all languages that can draw buttons and dropdowns but nobody has toppled the king yet for building advanced desktop GUIs (although there were a few close competitors in C# with WPF and Java with Swing they only solved the widget part in my opinion). I like to think iced can take this mantle one day, best of luck to them and congrats on the 0.14 release.
In case you’re not aware - Pop!_OS has built their cosmic desktop environment on top of iced.
On their fork of Iced.
They contribute back but it’s a notable distinction.
It feels a little cringe how Elm and the "Elm way of thinking" is so heavily emphasised, but after using Iced, IMO this is probably one of the best gui models without having to implement signals or message passing or IPCs like Dioxus/Tauri does with frontend/backend. Other key advantages Iced has includes daemon mode, native ability to use multi threading and also multi-window support
That said, for actually building most apps, what's more important is likely ease of learning and using the framework, platform/OS support, publishing support, etc, none of which Iced itself directly address.
Alternatively, Flutter desktop with flutter_rust_bridge works great. Sure, not fully Rust, but Flutter has way more packages on the GUI side than, I'd say, all of the Rust GUIs combined, simply due to how much older it is.
I'd rather use Tauri with any web front-end like React (which we do in my company)
and it's slow as molasses, at least in my experience
> When you start needing things like undo/redo you suspiciously start architecting something that smells like the elm architecture.
Well Iced itself claims to be inspired by the Elm Arch, so that checks out (see the first line under the Overview section of the Readme https://github.com/iced-rs/iced )
Right now Dioxus is looking good, specially after they stabilize their native renderer (Blitz)
For anyone curious about accessibility support, looks like it's a WIP with contributions from System76 staff <3 https://github.com/iced-rs/iced/issues/552
And TIL about AccessKit https://github.com/AccessKit/accesskit
I've got a stagnating Python Qt app prototype that I need to actually write properly. It's a personal project so I can do that without affecting users. I need to decide between Rust and Iced or stick with Python and Qt.
Python has a VLC library that embeds VLC behind the scenes for audio playback, and Qt had facility to work with it. This is terrific as I need to support a wide variety of codecs (voice recordings) and I need to change playback speed during playback. Does Rust or Iced have such capability to embed VLC? Not the VLC UI elements, just to use VLC behind the scenes.
This might be what you're looking for: https://docs.rs/vlc-rs/latest/vlc/
There's also PyO3 for using Python libraries from Rust, if no bindings or substitutes are available.
Nice, thank you! I see grt_rate() and set_rate() methods, so that might just work. I'll be setting up a prototype soon, much appreciated.
Iced is a wonderful dead-simple framework. I hope it forever maintains the simplicity which combines nicely with Rust’s features.
One thing I love about Iced and miss in Qt is writing the software in a single language. Qt has chosen to introduce multiple languages into their framework which makes the entire codebase a huge learning curve. In Qt you write your display layer in QML then your UI logic in Javascript and any backend advanced logic in C++. It is frankly exhausting.
In Iced you write in Rust and use Cargo packages. This gives the developer ultimate composability and clarity of their application as well as powerful tools from an established ecosystem. If Qt wanted to provide a powerful Qml tool, they have to write it and build all of the IDE integration.
For the record Qt used to be moving in a pure C++ direction but that changed when Qml came onto the scene.
I actually love that separation. QML is a great language for writing beautiful, responsive, modern UI with animations easily. C++ is great for performance and logic. I don't like Javascript but I don't need to write a whole lot of it. I wrote my note-taking app's block editor in QML and C++ if some people are curious[1].
[1] https://rubymamistvalove.com/block-editor
Yeah, I appreciate the separation as well actually, even though I'm not a fan of the langauges involved (no issue with QML, dislike JS and C++). I've made a few things with Qt and despite my feelings on the languages, found it to be pretty useful and capable, and the learning curve wasn't that bad imo. I can't recall using much JS to be honest, but it's been a hot minute since I worked with that.
That said there's simplicity to Iced being pure rust managed through cargo that I enjoy. Though it should be said that my "learning curve" for Iced was much lower than it might be for others as I discovered it well after I'd adopted Elm (which inspired Iced) and - independently - Rust, so Iced was pretty easy for me to grok.
I don't think there's a right/wrong way there to be honest, both approaches have their pro's/con's, and my main issues with Iced vs Qt is largely a matter of maturity/prevalence than any specifics with the implementations/workflow themselves.
I gave Notes/Plume a try a year or so ago, it was an interesting experience. I ended up falling back to Joplin as I could use it on macOS, iOS, and Fedora with synchronization via Dropbox.
I've always been curious about productizing apps like these, from a financial/business perspective have you found Daino worthwhile or enough of a success (by your standards) to continue developing it as a proprietary application?
Hi! That put a smile on my face (: I'm working now on a mobile version with real-time sync, so maybe give it another try when it comes out.
Not really, not yet. Once my FOSS app was popular I used to earn a livable amount of money from ads on the website. But after a SEO crash that all went down the drain and the money I'm getting now from subscriptions to Daino Notes is nice but not livable. I've been working the last year (at a really awesome place) doing React programming (my first salary job, actually) and at nights and weekends working on Daino.
I actually got many requests to license Daino Notes' block editor. So I've figured there's a business there. I'm working on something I'm calling Daino Qt which is a collection of different components to accelerate Qt apps development (so I'm also its client). It will include my block editor, components for mobile - current Qt components on mobile are extremly shitty - so I'm planning on changing that with things like native-feeling swipeable stack view, native-feeling text editing, etc. And maybe Qt C++ client SDK for InstantDB (and more stuff).
Hope I can sell this as well while also consuming these components for Daino Notes and other apps I will develop.
Did you ever write a pure C++ Qt application with QtWidgets?
Yes, my FOSS note-taking app[1] used to be pure Qt Widgets. Recently, I've added the Kanban feature that uses QML (this and the editor settings should be the only parts in QML, if I remember correctly).
[1] https://github.com/nuttyartist/notes
Haven't used Qt for a few years, but back then QML, QtQuick, etc have been optional features. You absolutely could write all your Qt logic in C++ only, in a somewhat similar way like the code shown in the iced READMEs. It is the same in any other classic GUI toolkit such as GTK+.
Biggest drawback in qt/c++ used to be the MOC. I guess they still have not gone rid of it, haven't they?
I write all my Qt in Python. I've never used the C++ bindings. But in Python you don't need to deal with QML or JavaScript.
I did some Qt programming in Python (PySide6), but ran into segfaults, which should of course not happen no matter what you do in a scripting language (except when using modules like ctypes). Many of these cases were related to object lifetime handling which is difficult to do correctly in Qt, and many people have written about it. In Python (a garbage-collected language) one should not have to worry about this.
I also use PySide. No segfaults, but I'm not doing anything complicated.
Are you writing QtWidgets or QtQuick in Python? My understanding is that QML is mandatory for QtQuick apps.
I use QtWidgets. I've never touched QtQuick.
The COSMIC DE (by System76, default in Pop_OS distro) is written using their iced fork, which hopefully will be upstreamed eventually.
Why did they fork it?
I believe it's a soft fork where they're treating Iced as upstream. Having their own fork just means they can land changes quicker.
The last iced release was September 2024, more than a year ago. I imagine they had constraints that made it impossible to wait for upstream patches to be merged (if at all) and it was simply more tenable to fork and worry about merging later.
they had release just yesteday but yeah, it's quite long between releases.
https://github.com/iced-rs/iced/releases/tag/0.14.0
For perspective Cosmic DE went from Alpha 1 to Beta 1 in that same timeframe.
They have needs that are specific to COSMIC, so they maintain a separate fork, but they update their fork to match the latest upstream release.
They also contribute to iced indirectly via cosmic-text and other crates.
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/) 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?
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
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!
Looking forward to trying out your app!
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
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.
>The master branch approach isn’t always ideal and people prefer having actual releases to base their work on.
I think this is me. My view is basically like this - if you use a tech you know works, you're only wrangling with your bugs. If you use a tech that is still being worked on, you are wrangling your bugs and the bugs of the tech you're using.
To be fair, I've tried this master branch thing with both Iced and PopOS's Iced fork. One year ago, PopOs's Iced fork was so slow I realised it basically wasn't going to be production ready for non Pop distros anytime soon.
IMO, both suffer from having very slow release cadence but at least dioxus has CSS
I appreciate the thoughtful replies. I struggle to understand why CSS is such a big deal if you're not building for the web. I can make my app as pretty as I'd like using styling that isn't CSS. OK, maybe I miss glow effects, some nicer gradients and 3D transforms, but those are far from showstoppers and still worth giving up for everything else I gain with iced
I don't have an eye for styling. That said, I have hundreds of hours of experience using CSS and frameworks such as tailwindCSS.
Of course, if I am being honest, the real reason is that there is so much CSS code out there, I can really find anything I need. And so can the LLMs.
Thanks. I've been meaning to make a shadcn-like library for iced. Would that help?
You bet! Shadcn is defacto component framework for a reason - it removes a lot of the mental load of design when you're an individual/small team building apps
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
I watched this video when it first came out. Honestly, the video is right in what it was trying to say. That said, that video didn't change my mind on whether to build on Dioxus and it should not for someone either.
The choice of framework should not be dependent on who else is building on that framework. Ideally the factors that matter: 1) Why are you building a GUI app on rust? 2) Target platform/OS support? 3) Are you ok with custom styling methods? Would you prefer to use CSS? 4) Need for multi threading? 5) Publishing / bundling / signing app
I think the reason Dioxus cadence release is slow is that they realised so many things are missing with the rust gui ecosystem that they decided they needed to fix these while building the main product. Guess what, this basically slows down your main product cadence. Does rust need a sub second hot reloader? Yes. Does rust need a native html/CSS renderer? Also probably yes. Did the Dioxus team have to take it on given their size and all the things pending in building rust with html + css? Armchair observer me thinks not.
*Note that I am currently building an app with Dioxus, so I'm putting out my honest opinion, and not saying that you shouldn't use it.*
There is also Slint, if you want another option. https://slint.dev
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
Repo: https://github.com/iced-rs/iced
I use Halloy, one of the applications featured in the readme, on the regular. It's great and the UI is very pleasant. I don't enjoy writing rust and very much wish someone would port iced to other languages.
From the GUI perspective, I hope Halloy correctly supports proportional fonts soon. They kinda work but not everything is aligned correctly.
tcl/tk in python is boring but gets the job done, and its not that hard to customise buttons with a canvas if you really want. i think its underrated.
Is there at least one Rust GUI library without something basic broken?
It would have helped if you told us what you think is broken in Iced.
You're right, unfortunately, don't have a good iced-specific list, so left it out, but here a few things: startup is blazingly slow (one of the big issues of all those awful electron apps which the native frameworks can supposedly avoid), https://github.com/iced-rs/iced/issues/2455 https://github.com/iced-rs/iced/issues/615.
Or high memory use, another fatal flaw of all those electron apps https://github.com/iced-rs/iced/issues/820
Or window can't be centered (while this is basic, it's in a bit of a blame-the-broken-Wayland niche https://github.com/iced-rs/iced/issues/1287)
Or lack of accessibility https://github.com/iced-rs/iced/issues/552
Or poor keybinding support (though in the case of iced I see it's somewhat improved in this release with some IME support and non-latin https://github.com/iced-rs/iced/pull/3134, so don't know exactly what's left broken)
The there are non-runtime issues like lack of documentation
My iced apps startup much faster than the Qt(Pyside) and Electron apps they replaced, and run faster too. Similarly, memory usage is much lower, and shipping a single 25MB binary to customers is preferable to bundling some multi-GB runtime environment. So in practice I'm glad development focuses more on completing the framework before playing performance metric golf, even if minimizing startup time and memory usage would be nice.
The 'lack' of documentation was only a problem for me when I was doing a cursory comparison of UI frameworks. Once I seriously started learning iced, the resources available, including the community on discord, was plenty to start being productive on making real apps within a week or two (and I had very limited Rust experience before that).
What are the exact timings? And what OS? For a Windows example, a proper native framework would be fractions of a second, Electron would be many seconds (especially on first run), iced would be a few seconds (as also noted in the issue linked), but that's still way closer to the Electron range, not the "instant" native feel.
Runtime speed is something different, even Electron is not that bad since the UIs are mostly too primitive to cause much of a visible slowdown, here the styling/animation capabilities are usually more prominent.
> including the community on discord
that's not a good baseline to cover the basics due to variable latency and predictability.
200-300ms on Windows 11, with ~70MB of idle RAM usage.
> that's not a good baseline to cover the basics
I wasn't suggesting that everyone should join the discord and ask how to write 'Hello World'. There's an official (but WIP) book, unofficial guides, and many examples spanning basic to advanced usage for reference. An active discord is complementary to those. Having more learning resources is important for wide adoption, but that's not the priority in pre-1.0 development.
> startup much faster than the Qt(Pyside) and Electron apps they replaced, and run faster too
I forgot to mention, the iced apps have taken less time to develop more features with fewer bugs (and no segfaults).
Strange, checked the latest version of a counter app, same slow startup ~2sec as before and ~70M ram vs a native simple window app that takes 0.2s and 1M.
When I switch to compiling with just the tiny-skia software renderer, the counter app is reduced to a 4MB binary that starts in 60ms (for first paint, 16ms for window creation) and takes 7M of RAM. So if you don't need GPU acceleration that may be more to your liking.
The RAM is from the wgpu buffer. It's not 70 ram for the counter. If you add 10,000 counters, it won't increase the ram.
Doesn't take 2 secs to load here, so maybe switch to a better OS
You had the chance to provide real feedback but instead chose to link to closed GH issues from 10 versions ago.
I encourage you to try and do better next time.
First, the issue is not a closed=solved issue, if you bothered to actually read it you'd realize there is another currently still opened issue about this, Second, there are no "issues", there is only one such link
I encourage you to read better next time and not close your eyes so tight as to miss the feedback.
Inspired by The Elm Architecture, Iced expects you to split user interfaces into four different concepts:
State — the state of your application
Messages — user interactions or meaningful events that you care about
View logic — a way to display your state as widgets that may produce messages on user interaction
Update logic — a way to react to messages and update your state