Why Idealyst over Dioxus?Dioxus is the closest project in spirit to Idealyst — a Rust UI framework targeting every platform, with a reactive component model. The honest answer to "why this and not that" comes down to a different default about who paints the pixels.
Credit where it's dueIdealyst uses Subsecond (the Dioxus team's hot-reload tooling) internally for fast iteration, and Taffy (their flexbox / grid layout engine) drives layout inside the iOS, Android, and wgpu backends. This project would have been a much bigger lift without that work. Their community is worth your attention regardless of which framework you end up choosing.
Different rendering strategyDioxus's mobile / desktop targets render through their own renderer — a step up from wrapping the app in a webview, but still not the platform's native widget set. UIKit / AppKit / Android Views aren't in the picture by default.Idealyst's default is the opposite: drive the platform's own toolkit. A `Button` is a real `UIButton`, a real Android button view, a real `NSButton`. The framework absorbs the per-toolkit differences below the primitive layer so author code stays portable, but the widget on the screen is the one the user's OS already knows how to render, animate, and make accessible.
If you want the GPU-renderer path, Idealyst supports it tooThere's a genuine case for a fully GPU-rendered app — custom visual identity, novel widgets that don't map onto native controls, embedded surfaces with no toolkit at all. Idealyst's wgpu backend is exactly that path: the same primitives, painted on a GPU surface instead of into a native view hierarchy. The bundled iPhone- and Android-skin simulators in the homepage demo are wgpu hosts.So the comparison isn't "Idealyst can't do what Dioxus does" — it can. It's that Idealyst's default is the native-SDK path and the GPU-renderer path is opt-in, whereas Dioxus picks the GPU-renderer path as the default everywhere.