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.