4 ms·

It would have helped if you told us what you think is broken in Iced.

by przmk 10mo ago

eviks 10mo ago
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/2455 https://github.com/iced-rs/iced/issues/615 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 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 https://github.com/iced-rs/iced/issues/1287) Or lack of accessibility https://github.com/iced-rs/iced/issues/552 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 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
- thorn132 10mo ago
  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).
  - eviks 10mo ago
    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.
    - thorn132 10mo ago
      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).
      - eviks 10mo ago
        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.
        thorn132 10mo ago
        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.
- airstrike 10mo ago
  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.
  - eviks 10mo ago
    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.
- deleted 10mo ago
  [deleted]

It would have helped if you told us what you think is broken in Iced.

by przmk 10mo ago

It would have helped if you told us what you think is broken in Iced.

eviks 10mo ago

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/2455 https://github.com/iced-rs/iced/issues/615 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 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 https://github.com/iced-rs/iced/issues/1287) Or lack of accessibility https://github.com/iced-rs/iced/issues/552 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 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

thorn132 10mo ago
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).
- eviks 10mo ago
  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.
  - thorn132 10mo ago
    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).
    - eviks 10mo ago
      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.
      - thorn132 10mo ago
        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.
airstrike 10mo ago
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.
- eviks 10mo ago
  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.
deleted 10mo ago
[deleted]