Hacker News Reader

Comment by creata | Hacker News Reader

What's the rationale for using Rust to write a UI? Using a scripting language (or at least a garbage-collected language) is much less restrictive, and it's not like the "what goes where" UI code is especially performance-sensitive.

View on HN

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.

The way Vello/Masonry/Xilem are split projects is partially what got me interested in it (and in turn caused me to post it to HN), as well as the reactive architecture of Xilem.

I do believe a garbage collected interpreted language would work best for UIs. Something like Vala (for gtk) but with a runtime/vm.

python-qt has shown to be a very strong combination. My issue with such solutions is that packaging a python application to the end-user can bloat binary size.

I also think GTK should get some credit in that space, because due to GObject introspection it's easy to interface with GTK with any language.

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.

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.

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

Unforgiving?

Hm, I believe my wording is bit unclear. The trait system can really get complex as your widget layout gets more complex, and you want to write reusable components, But there's no clear way to understand what's the type it's expecting from the errors. You need to really understand the traits to implement any reusable components. Which is why I felt it's kind of unforgiving, if you're not fully knowledgeable of the primitives.

But I'm still learning it, so, probably missing some details.

Iced is the clear number one for me, too. The only thing I'd love to see officially supported in iced in the future is mobile apps. But it looks like that ain't gonna happen anytime soon (with the most recent PRs getting rejected once again).

Have a question, what is the best way to detect if a `text_input` is focused?

Not exactly what you asked, but I recently answered a very similar question on StackOverflow: https://stackoverflow.com/questions/79345013/how-to-focus-te...

Yes, not what I want :-).

I can focus just fine. I want to detect if a text_input is focused, when I am checking key-presses.

But going through every discussion and all, there was a PR that might have allowed to do this, and it's been merged, but it's not working the way I want.

My use case is, If the text_input is not focused, I can press characters to perform some operations. If text_input is selected, it should be ignored.

For now I am back using modifiers, will get back to this later.

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

Afaik most UI are build with C/C++

Reply on news.ycombinator.com