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 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.
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).
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.
I never said that. Ofc Qt apps work just fine on any desktop environment you have (or even none), but they still look off if run Qt app on Gnome. Looking off == not native.
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!
While I love seeing many alternatives regarding UI frameworks, I'd love to see one general purpose "market leader".
I love `iced` for its simplicity and flexibility, but unfortunately there is no official software renderer, which makes it impossible to use for my little embedded side project.
`Slint` is also usable, however I'm not sure about the licensing approach that makes you pay for non open source projects (which is totally understandable, but somehow this feels like a no-go for the "leading" UI framework). The Slint UI DSL feels very good at first, but the more you use it, the more you run into limitations like missing async support for callbacks, the lack of importing structs from Rust into and export UI structs to Rust, etc. However, it at least supports a software renderer and framebuffer.
Is there any other lightweight UI Framework supporting software-rendering and framebuffer for embedded devices (RISC-V 64bit musl, LicheeRV Nano)?
> Is there any other lightweight UI Framework supporting software-rendering and framebuffer for embedded devices (RISC-V 64bit musl, LicheeRV Nano)?
There's no crates.io release yet, but the master branch of Xilem and Masonry is somewhat renderer-agnostic, and lets you use vello_cpu, which does SIMD-assisted software rendering (I don't know how good the RISC-V support is).
I say "somewhat" because it's supported by the internals crates (xilem_masonry, masonry_core), but not by the composition root crate (xilem), so you have to implement your own integration with winit, but we're getting there!
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.
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.
The only things I don't like about this is a) your binaries will become huge and very slow to compile with optimizations enabled and b) it's dependence on GPUI and its unsure future direction (I'd like to see GPUI thrive outside of Zed but the maintainers have clarified that that's not the goal for now).
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.
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.
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.
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.
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).
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.
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?
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?
> you can both look as native as the other, doesn't the actual UX matter more than how the implementation was made?
An Electron app that draws all its components mostly like the native controls will still not be native and have the same integrations etc. that native apps usually get.
You could get close but some things like for example "ctrl+f" search have native widgets that work different/look different that an electron app realistically won't have. Or for example you will never get the same liquid glass materials that macOS uses in an electron app.
So yea, native in my books means using the platform native (UI) apis. On Ubuntu for examples thats GTK, on Windows its.... idk at this point, WinUI? and on KDE it would be Qt.
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
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.
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.
Tested egui and it's great provided you accept the "immediate mode" and its limitations. It's quite polished nowadays although it misses in some areas.
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.
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.
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 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".
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
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.
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.
If it's compiled code, it's native.
Why would you need KDE to use Qt?
And IIRC Qt has a GTK theme nowadays that makes it look not terrible (high praise, I know).
Got a link or more info regarding the theme?
I never said that. Ofc Qt apps work just fine on any desktop environment you have (or even none), but they still look off if run Qt app on Gnome. Looking off == not native.
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!
While I love seeing many alternatives regarding UI frameworks, I'd love to see one general purpose "market leader".
I love `iced` for its simplicity and flexibility, but unfortunately there is no official software renderer, which makes it impossible to use for my little embedded side project.
`Slint` is also usable, however I'm not sure about the licensing approach that makes you pay for non open source projects (which is totally understandable, but somehow this feels like a no-go for the "leading" UI framework). The Slint UI DSL feels very good at first, but the more you use it, the more you run into limitations like missing async support for callbacks, the lack of importing structs from Rust into and export UI structs to Rust, etc. However, it at least supports a software renderer and framebuffer.
Is there any other lightweight UI Framework supporting software-rendering and framebuffer for embedded devices (RISC-V 64bit musl, LicheeRV Nano)?
> Is there any other lightweight UI Framework supporting software-rendering and framebuffer for embedded devices (RISC-V 64bit musl, LicheeRV Nano)?
There's no crates.io release yet, but the master branch of Xilem and Masonry is somewhat renderer-agnostic, and lets you use vello_cpu, which does SIMD-assisted software rendering (I don't know how good the RISC-V support is).
I say "somewhat" because it's supported by the internals crates (xilem_masonry, masonry_core), but not by the composition root crate (xilem), so you have to implement your own integration with winit, but we're getting there!
Isn't pure CPU rendering possible in iced with the tiny-skia backend?
Maybe... Is this framebuffer? My platform is pretty unusual (riscv64-musl), so I was pretty happy when something was working.
If your interested, it is a portable audio player with the size of the iPod Nano 7g:
https://github.com/nanowave-player/nanowave-ui
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.
QT does it well but the license is a maze
Qt is LGPL. Anything that's complicated about that is Qt Company sales tactics. It's really just LGPL.
Unless you were talking about commercial licenses - in that it's not that complicated neither; it's expensive.
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.
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.
> they reject PRs because they're not strictly related to Zed
What kind of PRs? Like new widget components or what?
Maybe https://github.com/longbridge/gpui-component would be more keen on accepting PRs like that?
IMO this is the best Rust GUI option at the moment:
https://github.com/longbridge/gpui-component
The only things I don't like about this is a) your binaries will become huge and very slow to compile with optimizations enabled and b) it's dependence on GPUI and its unsure future direction (I'd like to see GPUI thrive outside of Zed but the maintainers have clarified that that's not the goal for now).
hum, well, not that convincing :
Failed to open window: WebGPU context not initialized. Was Platform::run() called?
Not being able to load the component gallery does not inspire great confidence.
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.
Are we GUI Yet? The state of building user interfaces in Rust.
https://areweguiyet.com/
I recently added SDL3 to that page
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.
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.
[flagged]
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
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).
Unforgiving?
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++
If you want to learn more about Xilem's architecture I recommend Raph Levien's blogpost: https://raphlinus.github.io/rust/gui/2022/05/07/ui-architect...
I’d wager that it’s as native as Electron. It might be faster, sure, but it’s not native to any platform.
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.
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?
> you can both look as native as the other, doesn't the actual UX matter more than how the implementation was made?
An Electron app that draws all its components mostly like the native controls will still not be native and have the same integrations etc. that native apps usually get.
You could get close but some things like for example "ctrl+f" search have native widgets that work different/look different that an electron app realistically won't have. Or for example you will never get the same liquid glass materials that macOS uses in an electron app.
So yea, native in my books means using the platform native (UI) apis. On Ubuntu for examples thats GTK, on Windows its.... idk at this point, WinUI? and on KDE it would be Qt.
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
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 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.
Tested egui and it's great provided you accept the "immediate mode" and its limitations. It's quite polished nowadays although it misses in some areas.
Is there a plan for this to compete the experiment any time (soon)?
Why should I try to learn this instead of Slint?
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.
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 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.
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.
[dead]