Seems to be "native" as in "not a web-browser/view".

Native in the sense that it renders using the GPU directly (or rather via WebGPU) instead of relying on a webview.

On Linux you're right to say it's basically choosing between gtk and qt.

I recently added SDL3 to that page

Yes, we are collaborating closely with Linebender on Parley (the text engine) for which we have contributed a lot of code mostly for additional layout features (like the ability to layout images and other content inline with text).

And slightly less closely on the Vello renderers for which we haven't directly contributed much code, but which we support as backends for Blitz which we have used to help with validation and testing.

The last demo I saw just had a button so the chess app shows a lot of progress.

Cross platform GUI is extremely hard. Qt is the only good choice, even though it's still far from mature after 30 years of development.

IMO this is the best Rust GUI option at the moment:

https://github.com/longbridge/gpui-component

QT does it well but the license is a maze

Something like GPUI probably, I would be quite happy with it if it wasn't so tied and restricted by the Zed's team (they reject PRs because they're not strictly related to Zed), there's even mobile fork. Dioxus native would be second, but it's far far far away from being ready.

This is a perfectly reasonable question, and I think there are two aspects to it.

First, one of the research questions tested by Xilem is whether it is practical to write UI in Rust. It's plausible that scripting languages do end up being better, but we don't really know that until we've explored the question more deeply. And there are other very interesting explorations of this question, including Dioxus and Leptos.

Second, even if scripting languages do turn out to be better at expressing UI design and interaction (something I find plausible, though not yet settled), it's very compelling to have a high performance UI engine under a scriptable layer. I've done some experiments with Python bindings, and I think in an alternate universe you'd have apps like ComfyUI as high performance desktop app rather than a web page. Also, the layering of Xilem as the reactive layer, backed by Masonry as the widgets, is explicitly designed to be amenable to scripting, though to my knowledge there hasn't been a lot of actual work on this.

Same reason every other language has UI frameworks. It is more comfortable and nice to write the whole desktop program in the same language.

It's sometimes hard to package a scripting language project to the end-user. Rust compiles to a binary. That's one benefit for me.

Good thing about iced is, you get a compact executable, runs on any OS, looks exactly the same everywhere, perform much better than web based UI, no need to manage any permission to access local files, and you can customize the look as you need, but comes with tolerable default.

Price to pay is building the UI is bit complex as it doesn't hold your hand, unforgiving, and not native.

I like iced. But tauri is good middle ground

If you use a different language you have to deal with some kind of FFI and that's always painful.

Tech wise? If you have your UI in Rust it's both the safest and most performant language to implement it.

And you don't need to ship the entire web stack just to get GUI.

How so? It renders to a window buffer using your GPU API and interfaces with your OS for event handling. Electron renders using an embedded browser and uses said browser for input/events. Isn't that quite different?

> but it’s not native to any platform

Why is this still a talking point? So what if the app renders with AppKit or Cairo on macOS, you can both look as native as the other, doesn't the actual UX matter more than how the implementation was made?

raph wrote about that already: https://raphlinus.github.io/rust/gui/2022/07/15/next-dozen-g...

There is an Svg widget. It only supports static images, not animations, though this is certainly something I'm interested in.

It does support the modern 2D imaging model. It is in transition from using "Vello GPU" (aka Vello Classic) to the understory imaging abstraction, which means it can use any competent 2D renderer, including Skia.

To me it felt like it will break if I look at the code from down to up instead of up to down. And then I have to recompile flutter, the bridge and nuke the whole rust package folder to make sure it's clear and in workable state, then find other projects are now broke.

I joke, but probably rustdesk is so glued together, it created that bad impression on me.

This set of components is a nice compliment to GPUI: https://github.com/kiruhq/wgpui-component

Xilem is more like Iced but with it's own patterns and underlying graphics library.

I tried to play with GPUI for making a scratchpad like app with zed and It was one of the most rough experiences out there. They mention it in the readme though that it has rough edges but I hope that they make in the future more easier to tinker around.

But since this is a declarative framework, it gives you the very best of two worlds with only rust?

If Slint's licensing terms don't bother you, that's cool. They are more restrictive than most of the Rust ecosystem being dual Apache/MIT, though.

If you want to build a real app with a stable toolkit, use Slint.

Try Xilem if you want to experiment with new, experimental way to build UIs in Rust.