6 ms·

Iced – A cross-platform GUI library for Rust, inspired by Elm

220 points by maydemir 5y ago

DoctorOW 5y ago
Previous discussions: https://news.ycombinator.com/item?id=28326125 https://news.ycombinator.com/item?id=28326125 https://news.ycombinator.com/item?id=22766639 https://news.ycombinator.com/item?id=22766639
raphlinus 5y ago
So I read the 7 month old thread, and I found this comment particularly interesting: https://news.ycombinator.com/item?id=28332803 https://news.ycombinator.com/item?id=28332803 Basically, it answers the question, "why do Rust GUI frameworks use enums rather than closures for messages in the Elm update pattern?" It is very insightful, but doesn't tell the whole story. In particular, as a major counterexample, Druid does use closures for stuff like buttons, and they update state exactly as expected. That said, the Druid approach does have major drawbacks, chief among them that the app state needs a `Data` bound, which (oversimplifying slightly) means that it only works well with immutable data structures. As it turns out, I've been thinking about how to solve this problem - closures that have convenient access to mutable app state without strange bounds on that state, or strange control flow when doing things like adding and deleting widgets, and think I've finally cracked it. I will be doing a writeup when I have time, but for the eager and curious, there is a code sketch at https://github.com/linebender/druid/blob/lasagna/lasagna/src/rusty.rs https://github.com/linebender/druid/blob/lasagna/lasagna/src... .
- chaosprint 5y ago
  druid is really cool. it's great to see so many ui libraries (druid, iced, rui and egui) come out for rust.
- skywal_l 5y ago
  Interesting comment you are referencing to. I came into these problems when trying to implement the observer pattern with a similar interface than tc-39 proposal and banged my head against the same "limitations". The important take away I think: > our intuitions about using closures for this stuff in functional or garbage collected languages don't apply here--patterns that make a lot of sense in them don't work at all in Rust
chaosprint 5y ago
Before, I was not so sure whether I should use Message in my audio library design (https://github.com/chaosprint/glicol/tree/main/rs/synth https://github.com/chaosprint/glicol/tree/main/rs/synth). Now I feel more determined after I see the communication mechanism in this GUI lib.
osener 5y ago
Has anybody evaluated Rust GUI libraries that use custom rendering with Skia or custom OpenGL renderer (instead of QT or native controls) against each other? Iced looks interesting, but so does Druid [1], Slint (SixtyFPS) [2] and various immediate mode GUI libs. I want to build a UI that's similar in complexity to a text editor such as VSCode. I am basically looking for Rust equivalent of Revery [3] which has the programming model of React + Electron but compiles natively and draws with Skia without the browser or JS runtime. [1] https://github.com/linebender/druid https://github.com/linebender/druid [2] https://slint-ui.com/ https://slint-ui.com/ [3] https://www.outrunlabs.com/revery/ https://www.outrunlabs.com/revery/
- nkozyra 5y ago
  Just a question ... is the JS overhead really that substantial compared to the overall WebView integration? I wouldn't mind something like Tauri Studio if it just used js for design and had its own non browser rendering.
  - nicoburns 5y ago
    It's not open source, but https://sciter.com/ https://sciter.com/ is basically this. JS, but with a custom rendering engine that isn't web/DOM based.
    - deleted 5y ago
      [deleted]
- armchairhacker 5y ago
  See https://www.boringcactus.com/2020/08/21/survey-of-rust-gui-l https://www.boringcactus.com/2020/08/21/survey-of-rust-gui-l... (2020) and https://www.boringcactus.com/2021/10/24/2021-survey-of-rust- https://www.boringcactus.com/2021/10/24/2021-survey-of-rust-... (2021). These write-ups don’t evaluate performance, but i assume any of these libraries which use Qt/GTK/Electron are as performant as Qt/GTK/Electron, and the libraries which draw using Skia or OpenGL are very fast.

220 points by maydemir 5y ago

Previous discussions: https://news.ycombinator.com/item?id=28326125 https://news.ycombinator.com/item?id=28326125 https://news.ycombinator.com/item?id=22766639 https://news.ycombinator.com/item?id=22766639

raphlinus 5y ago

So I read the 7 month old thread, and I found this comment particularly interesting: https://news.ycombinator.com/item?id=28332803 https://news.ycombinator.com/item?id=28332803 Basically, it answers the question, "why do Rust GUI frameworks use enums rather than closures for messages in the Elm update pattern?" It is very insightful, but doesn't tell the whole story. In particular, as a major counterexample, Druid does use closures for stuff like buttons, and they update state exactly as expected. That said, the Druid approach does have major drawbacks, chief among them that the app state needs a `Data` bound, which (oversimplifying slightly) means that it only works well with immutable data structures. As it turns out, I've been thinking about how to solve this problem - closures that have convenient access to mutable app state without strange bounds on that state, or strange control flow when doing things like adding and deleting widgets, and think I've finally cracked it. I will be doing a writeup when I have time, but for the eager and curious, there is a code sketch at https://github.com/linebender/druid/blob/lasagna/lasagna/src/rusty.rs https://github.com/linebender/druid/blob/lasagna/lasagna/src... .

chaosprint 5y ago
druid is really cool. it's great to see so many ui libraries (druid, iced, rui and egui) come out for rust.
skywal_l 5y ago
Interesting comment you are referencing to. I came into these problems when trying to implement the observer pattern with a similar interface than tc-39 proposal and banged my head against the same "limitations". The important take away I think: > our intuitions about using closures for this stuff in functional or garbage collected languages don't apply here--patterns that make a lot of sense in them don't work at all in Rust

chaosprint 5y ago

Before, I was not so sure whether I should use Message in my audio library design (https://github.com/chaosprint/glicol/tree/main/rs/synth https://github.com/chaosprint/glicol/tree/main/rs/synth). Now I feel more determined after I see the communication mechanism in this GUI lib.

osener 5y ago

Has anybody evaluated Rust GUI libraries that use custom rendering with Skia or custom OpenGL renderer (instead of QT or native controls) against each other? Iced looks interesting, but so does Druid [1], Slint (SixtyFPS) [2] and various immediate mode GUI libs. I want to build a UI that's similar in complexity to a text editor such as VSCode. I am basically looking for Rust equivalent of Revery [3] which has the programming model of React + Electron but compiles natively and draws with Skia without the browser or JS runtime. [1] https://github.com/linebender/druid https://github.com/linebender/druid [2] https://slint-ui.com/ https://slint-ui.com/ [3] https://www.outrunlabs.com/revery/ https://www.outrunlabs.com/revery/

nkozyra 5y ago
Just a question ... is the JS overhead really that substantial compared to the overall WebView integration? I wouldn't mind something like Tauri Studio if it just used js for design and had its own non browser rendering.
- nicoburns 5y ago
  It's not open source, but https://sciter.com/ https://sciter.com/ is basically this. JS, but with a custom rendering engine that isn't web/DOM based.
  - deleted 5y ago
    [deleted]
armchairhacker 5y ago
See https://www.boringcactus.com/2020/08/21/survey-of-rust-gui-l https://www.boringcactus.com/2020/08/21/survey-of-rust-gui-l... (2020) and https://www.boringcactus.com/2021/10/24/2021-survey-of-rust- https://www.boringcactus.com/2021/10/24/2021-survey-of-rust-... (2021). These write-ups don’t evaluate performance, but i assume any of these libraries which use Qt/GTK/Electron are as performant as Qt/GTK/Electron, and the libraries which draw using Skia or OpenGL are very fast.