alt.hn

4/7/2026 at 11:36:15 PM

Xilem – An experimental Rust native UI framework

 https://github.com/linebender/xilem

by Levitating

4/8/2026 at 5:27:17 PM

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)?

by sandreas

4/8/2026 at 6:05:31 PM

Isn't pure CPU rendering possible in iced with the tiny-skia backend?

by FrankenApps

4/8/2026 at 6:11:36 PM

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

by sandreas

4/8/2026 at 7:17:04 PM

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/

by nicoburns

4/8/2026 at 10:31:40 AM

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.

by alfanick

4/8/2026 at 10:43:22 AM

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

by longor1996

4/8/2026 at 10:48:47 AM

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

by raphlinus

4/8/2026 at 11:06:47 AM

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.

by alfanick

4/8/2026 at 12:22:52 PM

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.

by Levitating

4/8/2026 at 5:15:46 PM

If it's compiled code, it's native.

by 201984

4/8/2026 at 1:53:47 PM

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).

by Pay08

4/8/2026 at 3:23:35 PM

Got a link or more info regarding the theme?

by avtar

4/8/2026 at 3:45:11 PM

I was thinking of breeze-gtk[0] but that's KDE-specific.

[0]: https://github.com/KDE/breeze-gtk

by Pay08

4/8/2026 at 4:46:34 PM

It’s literally the other way around - “GTK theme that looks like Qt”.

by alfanick

4/8/2026 at 4:54:02 PM

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.

by Pay08

4/8/2026 at 4:41:40 PM

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.

by alfanick

4/8/2026 at 4:56:03 PM

I didn't take your message to mean you need Plasma specifically, I interpreted it as you needing some library from KDE.

by Pay08

4/8/2026 at 5:13:07 AM

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

by malekpour

4/8/2026 at 9:38:13 AM

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.

by nicoburns

4/8/2026 at 1:25:17 AM

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!

by sheepscreek

4/8/2026 at 10:36:05 AM

Are we GUI Yet? The state of building user interfaces in Rust.

https://areweguiyet.com/

by mellosouls

4/8/2026 at 12:23:27 PM

I recently added SDL3 to that page

by Levitating

4/8/2026 at 3:04:06 AM

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.

by brainless

4/8/2026 at 3:13:07 AM

QT does it well but the license is a maze

by synergy20

4/8/2026 at 4:51:38 AM

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.

by feverzsj

4/8/2026 at 5:23:24 AM

FWIW Slint was founded by a group of long time Qt alumni, so brings a lot of that know-how into the space.

by dafelst

4/8/2026 at 9:06:17 AM

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.

by noodletheworld

4/8/2026 at 1:23:56 PM

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

by jenadine

4/8/2026 at 3:22:08 AM

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.

by tvshtr

4/8/2026 at 12:55:36 PM

> 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?

by Levitating

4/8/2026 at 1:04:36 PM

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

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

by IshKebab

4/8/2026 at 6:11:23 PM

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).

by FrankenApps

4/8/2026 at 1:54:50 AM

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.

by mtndew4brkfst

4/8/2026 at 4:46:55 AM

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

by wmf

4/8/2026 at 6:23:39 AM

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.

by creata

4/8/2026 at 9:32:13 AM

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.

by raphlinus

4/8/2026 at 1:31:06 PM

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.

by Levitating

4/8/2026 at 12:29:16 PM

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.

by Levitating

4/8/2026 at 6:43:17 AM

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

by QuantumNomad_

4/8/2026 at 7:06:33 AM

[flagged]

by jauntywundrkind

4/8/2026 at 7:13:27 AM

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.

by creata

4/8/2026 at 8:26:31 AM

> 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.

by jauntywundrkind

4/8/2026 at 11:17:47 AM

> 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?

by embedding-shape

4/8/2026 at 8:13:33 AM

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

by t_mahmood

4/8/2026 at 6:14:29 PM

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).

by FrankenApps

4/8/2026 at 11:50:01 AM

Unforgiving?

by tcfhgj

4/8/2026 at 2:08:55 PM

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.

by t_mahmood

4/8/2026 at 7:13:24 AM

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.

by Ygg2

4/8/2026 at 1:06:00 PM

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

by IshKebab

4/8/2026 at 8:07:31 AM

I’d wager that it’s as native as Electron. It might be faster, sure, but it’s not native to any platform.

by pointlessone

4/8/2026 at 12:28:03 PM

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?

by Levitating

4/8/2026 at 11:15:29 AM

> 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?

by embedding-shape

4/8/2026 at 11:38:31 AM

> 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.

by ghosty141

4/8/2026 at 11:55:43 AM

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?

by embedding-shape

4/8/2026 at 2:27:31 PM

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.

by ghosty141

4/8/2026 at 4:04:07 PM

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?

by embedding-shape

4/8/2026 at 5:15:01 PM

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.

by wmf

4/8/2026 at 11:52:47 AM

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.

by nicoburns

4/8/2026 at 8:35:56 AM

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

by bananapub

4/8/2026 at 10:59:42 AM

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.

by pointlessone

4/8/2026 at 5:06:41 AM

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

by amarant

4/8/2026 at 12:54:28 PM

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.

by wiz21c

4/8/2026 at 3:41:32 AM

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.

by _stillmind

4/8/2026 at 8:05:56 AM

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.

by t_mahmood

4/8/2026 at 11:07:19 AM

what's the difference between Xilem and GPUI? GPUI is used in zed and pretty cool!

by wangii

4/8/2026 at 12:36:31 PM

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.

by Levitating

4/8/2026 at 11:20:38 AM

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.

by Imustaskforhelp

4/8/2026 at 3:35:39 AM

Is there a plan for this to compete the experiment any time (soon)?

by eviks

4/8/2026 at 9:12:27 AM

Can it render SVG with all of its features? (Does it support all modern 2D drawing primitives)

by amelius

4/8/2026 at 9:25:57 AM

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.

by raphlinus

4/8/2026 at 5:12:47 AM

Why should I try to learn this instead of Slint?

by CapricornNoble

4/8/2026 at 11:35:45 AM

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.

by mtndew4brkfst

4/8/2026 at 6:15:07 AM

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.

by jenadine

4/8/2026 at 3:08:52 AM

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.

by sourcegrift

4/8/2026 at 3:34:30 AM

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

by eviks

4/8/2026 at 6:21:59 AM

The thing about Qt is the maturity ("tried and tested"). Xylem doesn't give you that.

by jenadine

4/8/2026 at 1:04:09 PM

[dead]

by Serhii-Set