Iced.rs didn't work out (a web dev's experience)

Well, I’ve been learning Rust. Being a web dev, Rust is exciting territory. After working on some toy projects, I decided it was time to contribute to some open-source projects. Building GUIs with Rust always fascinated me so I kept looking for projects to work on.

The first exciting project I found was Sniffnet, a GUI app to monitor internet traffic. I went through the codebase. It uses Iced.rs for rendering. I spent hours building UIs in Iced.rs. After a few days, I gave up. There are multiple reasons:

This is just a self documentation. Don’t take seriously. I’m not a Rust expert.

Lack of Documentation

This is usually the case for many Rust libraries. Maybe I’m not smart enough to learn from examples? But, I believe, a documentation is a requirement for any library (or product). The Rust Book itself is a great example.

Iced.rs’s lack of documentation was the main reason to give up. They, however, are working on a book. And, the creator has an excellent introductory video to get started.

I could look at the structs and implementations and build the things I wanted, but it is the way the library is supposed to be used? I’ll never know without documentation with examples.

Everything is global

Iced.rs uses the Elm architecture. A basic application would look like this:

 1fn main() -> iced::Result {
 2	MyApplication::run(Settings::default())
 3}
 4
 5struct MyApplication {
 6	my_state: usize
 7}
 8
 9// messages of the application
10#[derive(Debug)]
11enum Message {}
12
13impl iced::Application for MyApplication {
14	type Message = Message;
15	
16	fn new()... // creates the application
17	fn update()... // handles messages
18	fn view()... // view
19}

  • The (only) application state is saved in the struct MyApplication. There are no local states like in Components.

  • All the messages are saved in enum Message.

  • the update() method updates the application state.

  • the view() method renders the view.

I didn’t come to enjoy this. It may be culture shock after working years on component-based libraries like React and Svelte.

However, when working on the Sniffnet project, I felt the code is “ugly”. There is some code that handles the logic of a modal view inside settings along with some other code that handles the main UI view. This lack of logical separation didn’t make sense to me. I know folks who love the Elm architecture. Maybe I’ll change my opinion in the future, but it’s a no now.

No debugger

To debug, you have to re-run the whole app. The fancy browser debugger isn’t there to help. In a web app, if something is wrong, you find the .class and search for it in the app. But, in Iced.rs, there are variables with different names. It took me a long while to find where the related code of a particular UI is located in the Sniffnet source code. This made me realize how important the browser debugger is! Maybe there’s an easy way to debug, but where’s the documentation? You say, find the component? But, where are the components?.

Accessibility

The next problem was that iced.rs’s accessibility support was still in the early ages (see this issue). Some basic events like focus are not yet supported.

Again, this made me realize how amazing the Web Accessibility standards are. These were developed over many years into the state we have now. Iced.rs is new. It’s not easy to get accessibility right. There are many platform-specific issues to solve.

Closing thoughts

Iced.rs is definitely a great project. You can definitely build great cross-platform apps with it. But, it wasn’t for me. Next week, I’m going to explore Tauri, which has more ties to web development than other alternatives.

Rust