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.
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)?
You might need to modify it slightly to get it to render to the right location, but it's a pure software renderer. You could ask in the Iced zulip https://iced.zulipchat.com/
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.
Slint has nothing to do with elecron.
There is no browser under the hood so it is much more lightweight.
Slint has native looking widgets.
Slint DSL gets compiled to native code: no need for a runtime interpreter like in QtQuick
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).
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.
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.
You can get all those things in a Rust application drawing with Cairo on macOS, but that isn't "native" according to you regardless, because it's using Cairo instead of AppKit/SwiftUI?
Again I don't understand the obsession with caring so deeply about the implementation, as long as the end results are the same, why it matters so much?
My point is practically you don't get the same results unless you use the native APIs the the platform provides.
Take my Liquid Glass for example, you simply won't be able to match the look in an electron app in practice.
Ofc if the result is the same it doesn't matter how, but in reality it's almost impossible to imitate the look and capabilities since it would require a Herculean effort to keep feature parity.
Right, but you could call native APIs from JavaScript or Java say, then in your world that's a "native" application because it uses the APIs the platform provides, regardless of how it actually was implemented? Meanwhile, an application could be implemented with Objective-C and/or Swift but not use Cacoa/AppKit/SwiftUI APIs, then that's not an native application because it doesn't look like one? Like games written with Vulkan/OpenGL aren't "as native" as one using Metal I'd presume?
you could call native APIs from JavaScript or Java say, then in your world that's a "native" application because it uses the APIs the platform provides
Yes, this is what we want.
an application could be implemented with Objective-C and/or Swift but not use Cacoa/AppKit/SwiftUI APIs, then that's not an native application
Correct. The toolkit matters, not the language. Native toolkits have very rich and subtle behavior that cannot be properly emulated. They also have a lot of features (someone mentioned input methods and accessibility) that wrappers or wannabe toolkits often lack. To get somewhat back on topic I notice and appreciate that Xilem mentions accessibility.
games written with Vulkan/OpenGL aren't "as native"...
Games are usually fullscreen and look nothing like desktop apps anyway so it doesn't matter what API they use.
You can technically get those platform native things by integrating with the native APIs. There's basically a full spectrum from "native" to "custom" rather than it being either-or.
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.
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
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.
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.
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.
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.
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.
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 was thinking of breeze-gtk[0] but that's KDE-specific.
[0]: https://github.com/KDE/breeze-gtk
It’s literally the other way around - “GTK theme that looks like Qt”.
To be extremely pedantic, I never said it was a Qt theme :P
I said that Qt has a GTK theme. It doesn't, but KDE does have a GTK 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.
I didn't take your message to mean you need Plasma specifically, I interpreted it as you needing some library from KDE.
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)?
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
You might need to modify it slightly to get it to render to the right location, but it's a pure software renderer. You could ask in the Iced zulip https://iced.zulipchat.com/
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.
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.
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.
Slint has nothing to do with elecron. There is no browser under the hood so it is much more lightweight. Slint has native looking widgets. Slint DSL gets compiled to native code: no need for a runtime interpreter like in QtQuick
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?
For example https://github.com/zed-industries/zed/pull/42905#issuecommen...
So there is now a fork: https://github.com/gpui-ce/gpui-ce/ But I don't know if that's sustainable.
That's disheartening, though also understandable from Zeds point of view.
I hope the community fork could gain traction. I believe there's a lot of potential in GPUI.
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.
Yeah it just doesn't have a good error message if your browser doesn't support WebGPU.
It's not really designed for the web though so I wouldn't hold that against it.
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.
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
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?
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.
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.
If you use a different language you have to deal with some kind of FFI and that's always painful.
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.
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.
You can get all those things in a Rust application drawing with Cairo on macOS, but that isn't "native" according to you regardless, because it's using Cairo instead of AppKit/SwiftUI?
Again I don't understand the obsession with caring so deeply about the implementation, as long as the end results are the same, why it matters so much?
My point is practically you don't get the same results unless you use the native APIs the the platform provides.
Take my Liquid Glass for example, you simply won't be able to match the look in an electron app in practice.
Ofc if the result is the same it doesn't matter how, but in reality it's almost impossible to imitate the look and capabilities since it would require a Herculean effort to keep feature parity.
Right, but you could call native APIs from JavaScript or Java say, then in your world that's a "native" application because it uses the APIs the platform provides, regardless of how it actually was implemented? Meanwhile, an application could be implemented with Objective-C and/or Swift but not use Cacoa/AppKit/SwiftUI APIs, then that's not an native application because it doesn't look like one? Like games written with Vulkan/OpenGL aren't "as native" as one using Metal I'd presume?
you could call native APIs from JavaScript or Java say, then in your world that's a "native" application because it uses the APIs the platform provides
Yes, this is what we want.
an application could be implemented with Objective-C and/or Swift but not use Cacoa/AppKit/SwiftUI APIs, then that's not an native application
Correct. The toolkit matters, not the language. Native toolkits have very rich and subtle behavior that cannot be properly emulated. They also have a lot of features (someone mentioned input methods and accessibility) that wrappers or wannabe toolkits often lack. To get somewhat back on topic I notice and appreciate that Xilem mentions accessibility.
games written with Vulkan/OpenGL aren't "as native"...
Games are usually fullscreen and look nothing like desktop apps anyway so it doesn't matter what API they use.
You can technically get those platform native things by integrating with the native APIs. There's basically a full spectrum from "native" to "custom" rather than it being either-or.
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.
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
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.
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)?
what's the difference between Xilem and GPUI? GPUI is used in zed and pretty cool!
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.
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.
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.
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.