What's native about it? It seems like custom GPU rendered thingy with nothing "native".
Linux GUI frameworks are hot potato, I tried to write "native-feeling" app with taskbar icon lately on Linux (Cinnamon), intuition says GTK3, Internet says GTK4. Cinnamon says write it in JS and plug it in as an applet. Qt seems like the most complete GUI framework, but I don't like KDE (and Qt on mostly GTK based env looks weird). Windows is the same, Microsoft has like 10 different UI frameworks from different epochs. MacOS seems to be the only one with some common UI framework.
It's a step forward. If someone makes an app which is some Electron/WebView thing and call it "native", my thoughts are immediately rather illegal. Cool, so it's UI framework that doesn't actually make a webpage presented as an app. Truly native for me means: using UI framework that is the gold standard for given OS, UX native for given OS, and using native OS APIs, so my laptop can actually survive 24h on battery. It's truly hilarious that Claude app (and ChatGPT) is just Electron app - argument that writing UI in Electron is cheaper is no longer valid in AI age, but yet they did it. Weird times.
Indeed. I try not to use the word "native" these days as it has such ambiguous meaning. I also have thought for a while that Windows no longer has native UI, only legacy (Win32) and a rotating carousel of mostly-failed attempts. There have been a few HN stories in the last week that bear me out, notably [1]. Mac of course is in better shape, as AppKit and SwiftUI are both viable (and interop well enough).
I've done a small project with Dioxus on Blitz. It is principally very close to Xilem and in fact is using some of the Xilem components. https://github.com/DioxusLabs/blitz
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.
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.
Was there some new developments with this project that renewed interest recently? I started learning Rust in 2018 or 2019 and I think "good Rust GUI" research is probably at least that old.
Been using it with mixed success. While I love vello, Xilem is less mature in comparison. Many standard UI components, such as selection box, are not implemented yet. On the other hand, it’s a great opportunity to become a contributor towards a genuinely useful and promising project!
I keep trying Xilem and then egui or Iced. Xilem needs more widgets out of the box to be easy to build with. Slint is another option. I wonder what cross platform GUI framework (from any language) will finally become as common as Electron based apps or the vast number of native OS apps in Windows or macOS or Linux.
I keep going back to Tauri, which is practical to build desktop apps quickly but still uses HTML, CSS, JS to build the UI. You can use Rust web UI tools but then it is still (system) browser based.
I gave it a decent shot, and I wanted to like slint, but I don’t.
It’s not a rust ui system; it’s a declarative ui language that happens to have a rust binding via macros so you can write the custom DSL.
It also has bindings for other languages.
It feels like a bunch of qtquick people got together and implemented a new runtime for qtquick. That might be the direction qt has gone, at the expense of their c++ qtwigets system, but it just feels… “electron app” to me.
If I wanted an electron app, I would just use electron.
If I wanted a non-native ui look and feel, I would use flutter.
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.
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?
I agree that there’s chaos everywhere and system integration on individual axes is a better way to look at it but then it turns out that Electron is more native than most GUI libs out there. Browser devs worked very hard and for a long time to integrate with host OSes. Browsers have native text rendering, good accessibility, IME support on all platforms, etc. All these features are usually missing from the hot new UI libs.
ImHex is a great hex editor, lots of features. It’s got antialiased fonts like only a year ago. Fonts still look not exactly as the rest of the OS. Has no accessibility integration at all.
Zed, looks pretty good at first glance. No accessibility.
“Native” implies all the features that the platform provides. It is chaotic on all major platofrms but it’s still meaningful.
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.
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.
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.
These people are such jackasses. What's the reason to not use assembly? To not frelling suffer in hell. To have a system that works well together, that gives us a stable base, without infinite danger everywhere.
It's so sad having such perpetuate drains asking only negative vortex energy sink ass questions. No attempt to show any real outreach or curiosity or interest, all sucking nihil void of doubt. No demonstrated ability to offer any useful assessment, just pure sucking doubt.
Good faith questions show some concomitant interest or ability to recognize whats at stake. The harmless innocent child offering savage nothing? I tire of that act.
I have been watching people write UI frameworks in Rust for over a decade, you meanie.
The results tend to involve more dynamic allocation than you'd see in a garbage-collected language, or tons of reference counting (e.g., in Leptos) that acts as a less efficient GC. I've read many of raphlinus's posts, and while they're always interesting, the total experience in the Xilem examples just seems like much more effort than using FFI (even C FFI) to glue to something more workable.
Your comparison to assembly is very bizarre - languages of the sort I mentioned are usually at least as safe as Rust, and the "scripting language for top-level logic + compiled language for the bits that need to be fast" combination is ancient. In fact, your vague allusions to "a stable base, without infinite danger everywhere" shows much less understanding of what's at stake, in my view.
I'm sorry my question wasn't enlightened enough for you.
And this is a news aggregator. Not the official discussion forums or anything. People can ask small insignificant questions here, or so I thought.
I'm so tired. You write one measly paragraph that could simply be ignored and someone calls you a "perpetuate drain". Even the chatbots have more humanity than you've got.
> I'm so tired. You write one measly paragraph that could simply be ignored and someone calls you a "perpetuate drain". Even the chatbots have more humanity than you've got.
Don't tire everyone else out by asking open ended draining questions. Show some engagement, before doing what looks like a discarding.
You've shown you have some interest or connection to the situation, with your reply. None of that was present before, in your 'just-asking-questions' "measely paragraph". It looked like just another anti-rust anti-systemd anti-pipewire/pulseaudio anti-wayland drain, only sapping energies without showing faintest attempts at engaging. Offer something, try to have some positive sum.
We are all so tired. Why be a vacuum, why drain us, like you did? Critical review is fine! But show some engagement, offer something yourself, when doing so.
> Don't tire everyone else out by asking open ended draining questions
What are you on about? If you're so tired, don't put it on yourself to answer these "open ended draining questions". Internet continues to work the same way as before, anyone writes whatever they feel like, others engage, if you don't want, don't. But it's not up to you what questions are acceptable or not, what kind of world view is that?
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.
Given the similarity in "inspired by" projects, how does this compare to iced? I've found iced to be surprisingly mature in every aspect I've tried, except the documentation, which is severely lacking
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.
Very happy with qmetaobject-rs. Qt is tried and tested, dnd multi platform. Also, UI itself is best done declaratively not imperatively. Qmetaobject-rs gives you the best of both worlds: great UI declaratively, logic in Rust.
What's native about it? It seems like custom GPU rendered thingy with nothing "native".
Linux GUI frameworks are hot potato, I tried to write "native-feeling" app with taskbar icon lately on Linux (Cinnamon), intuition says GTK3, Internet says GTK4. Cinnamon says write it in JS and plug it in as an applet. Qt seems like the most complete GUI framework, but I don't like KDE (and Qt on mostly GTK based env looks weird). Windows is the same, Microsoft has like 10 different UI frameworks from different epochs. MacOS seems to be the only one with some common UI framework.
Seems to be "native" as in "not a web-browser/view".
It's a step forward. If someone makes an app which is some Electron/WebView thing and call it "native", my thoughts are immediately rather illegal. Cool, so it's UI framework that doesn't actually make a webpage presented as an app. Truly native for me means: using UI framework that is the gold standard for given OS, UX native for given OS, and using native OS APIs, so my laptop can actually survive 24h on battery. It's truly hilarious that Claude app (and ChatGPT) is just Electron app - argument that writing UI in Electron is cheaper is no longer valid in AI age, but yet they did it. Weird times.
Indeed. I try not to use the word "native" these days as it has such ambiguous meaning. I also have thought for a while that Windows no longer has native UI, only legacy (Win32) and a rotating carousel of mostly-failed attempts. There have been a few HN stories in the last week that bear me out, notably [1]. Mac of course is in better shape, as AppKit and SwiftUI are both viable (and interop well enough).
[1]: https://news.ycombinator.com/item?id=47651703
Are we GUI Yet? The state of building user interfaces in Rust.
https://areweguiyet.com/
I've done a small project with Dioxus on Blitz. It is principally very close to Xilem and in fact is using some of the Xilem components. https://github.com/DioxusLabs/blitz
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.
what's the difference between Xilem and GPUI? GPUI is used in zed and pretty cool!
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.
Was there some new developments with this project that renewed interest recently? I started learning Rust in 2018 or 2019 and I think "good Rust GUI" research is probably at least that old.
The last demo I saw just had a button so the chess app shows a lot of progress.
Been using it with mixed success. While I love vello, Xilem is less mature in comparison. Many standard UI components, such as selection box, are not implemented yet. On the other hand, it’s a great opportunity to become a contributor towards a genuinely useful and promising project!
I keep trying Xilem and then egui or Iced. Xilem needs more widgets out of the box to be easy to build with. Slint is another option. I wonder what cross platform GUI framework (from any language) will finally become as common as Electron based apps or the vast number of native OS apps in Windows or macOS or Linux.
I keep going back to Tauri, which is practical to build desktop apps quickly but still uses HTML, CSS, JS to build the UI. You can use Rust web UI tools but then it is still (system) browser based.
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.
FWIW Slint was founded by a group of long time Qt alumni, so brings a lot of that know-how into the space.
I gave it a decent shot, and I wanted to like slint, but I don’t.
It’s not a rust ui system; it’s a declarative ui language that happens to have a rust binding via macros so you can write the custom DSL.
It also has bindings for other languages.
It feels like a bunch of qtquick people got together and implemented a new runtime for qtquick. That might be the direction qt has gone, at the expense of their c++ qtwigets system, but it just feels… “electron app” to me.
If I wanted an electron app, I would just use electron.
If I wanted a non-native ui look and feel, I would use flutter.
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.
QT does it well but the license is a maze
I’d wager that it’s as native as Electron. It might be faster, sure, but it’s not native to any platform.
> 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...
I agree that there’s chaos everywhere and system integration on individual axes is a better way to look at it but then it turns out that Electron is more native than most GUI libs out there. Browser devs worked very hard and for a long time to integrate with host OSes. Browsers have native text rendering, good accessibility, IME support on all platforms, etc. All these features are usually missing from the hot new UI libs.
ImHex is a great hex editor, lots of features. It’s got antialiased fonts like only a year ago. Fonts still look not exactly as the rest of the OS. Has no accessibility integration at all.
Zed, looks pretty good at first glance. No accessibility.
“Native” implies all the features that the platform provides. It is chaotic on all major platofrms but it’s still meaningful.
Can it render SVG with all of its features? (Does it support all modern 2D drawing primitives)
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.
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.
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.
These people are such jackasses. What's the reason to not use assembly? To not frelling suffer in hell. To have a system that works well together, that gives us a stable base, without infinite danger everywhere.
It's so sad having such perpetuate drains asking only negative vortex energy sink ass questions. No attempt to show any real outreach or curiosity or interest, all sucking nihil void of doubt. No demonstrated ability to offer any useful assessment, just pure sucking doubt.
Good faith questions show some concomitant interest or ability to recognize whats at stake. The harmless innocent child offering savage nothing? I tire of that act.
I have been watching people write UI frameworks in Rust for over a decade, you meanie.
The results tend to involve more dynamic allocation than you'd see in a garbage-collected language, or tons of reference counting (e.g., in Leptos) that acts as a less efficient GC. I've read many of raphlinus's posts, and while they're always interesting, the total experience in the Xilem examples just seems like much more effort than using FFI (even C FFI) to glue to something more workable.
Your comparison to assembly is very bizarre - languages of the sort I mentioned are usually at least as safe as Rust, and the "scripting language for top-level logic + compiled language for the bits that need to be fast" combination is ancient. In fact, your vague allusions to "a stable base, without infinite danger everywhere" shows much less understanding of what's at stake, in my view.
I'm sorry my question wasn't enlightened enough for you.
And this is a news aggregator. Not the official discussion forums or anything. People can ask small insignificant questions here, or so I thought.
I'm so tired. You write one measly paragraph that could simply be ignored and someone calls you a "perpetuate drain". Even the chatbots have more humanity than you've got.
> I'm so tired. You write one measly paragraph that could simply be ignored and someone calls you a "perpetuate drain". Even the chatbots have more humanity than you've got.
Don't tire everyone else out by asking open ended draining questions. Show some engagement, before doing what looks like a discarding.
You've shown you have some interest or connection to the situation, with your reply. None of that was present before, in your 'just-asking-questions' "measely paragraph". It looked like just another anti-rust anti-systemd anti-pipewire/pulseaudio anti-wayland drain, only sapping energies without showing faintest attempts at engaging. Offer something, try to have some positive sum.
We are all so tired. Why be a vacuum, why drain us, like you did? Critical review is fine! But show some engagement, offer something yourself, when doing so.
> Don't tire everyone else out by asking open ended draining questions
What are you on about? If you're so tired, don't put it on yourself to answer these "open ended draining questions". Internet continues to work the same way as before, anyone writes whatever they feel like, others engage, if you don't want, don't. But it's not up to you what questions are acceptable or not, what kind of world view is that?
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
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.
Given the similarity in "inspired by" projects, how does this compare to iced? I've found iced to be surprisingly mature in every aspect I've tried, except the documentation, which is severely lacking
Why not just use Flutter with Rust, via the flutter_rust_bridge (https://cjycode.com/flutter_rust_bridge/quickstart)? Seems like a reasonable combo to me.
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.
Is there a plan for this to compete the experiment any time (soon)?
Very happy with qmetaobject-rs. Qt is tried and tested, dnd multi platform. Also, UI itself is best done declaratively not imperatively. Qmetaobject-rs gives you the best of both worlds: great UI declaratively, logic in Rust.
But since this is a declarative framework, it gives you the very best of two worlds with only rust?
The thing about Qt is the maturity ("tried and tested"). Xylem doesn't give you that.
Why should I try to learn this instead of Slint?
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.