If you're interested in a GPU-rendered Rust UI framework, then maybe skip this vibe coded project, and check out some of following established projects:
List is hand-picked list, ordered by crates.io downloads. I had an LLM fetch the download counts and links. Webview based UI like Tauri and Dioxus Desktop are excluded. As are bindings to native toolkits and GTK.
IMO, the top GUI framework crates for Rust are windows or native-windows-gui, objc2 or icrate for MacOS and gtk4-rs for Linux only. Actually for MacOS / iOS I'd use uniffi to embed the rust core in a SwiftUI app.
In 2026 IMO it's much better to use an LLM to keep 3 separate native front ends in sync than it is to try and use any sort of cross platform UI.
Could you please explain why? For example: Is it colors? A je-ne-sais-quoi? Widget rounding size and fonts? Performance reasons? Keyboard shortcuts? Do you really find it's easier to maintain 3 separate frontends using an LLM than using EGUI, GPUI, QT etc?
I have seen this suggestion several times recently regarding GUI framework threads on HN in the past week (There has been a surge!), but they are always described in the way you did: With no explanation of why. Just an assertion that native UI kits (of which you need a separate one for each OS family) are superior; cross-platform kids are an "inferior experience" etc. I have asked at 3 times and received no answer. I say this as someone who uses both Windows and Linux regularly, and find they are functionally equivalent once you have an application launched. There are ABI differences, driver differences, file system differences, etc which need to be smoothed over with feature gates for certain application functionality, if you're using certain functionality.
I want my applications to have the required functionality, run fast, and have a good UI. I don't care if the widgets look the same as on my other applications or the ones built in to the OS; this isn't even a thing because there is so little standardization broadly. Maybe on Macs it's standardized and cross-platform kits look out of place?
The proposed approach of "Use LLMs to vibe-code a system of 3 native kits" has cons to weigh. Or making your program Windows only or w/e for a look-and-feel reason or whatever it is has cons too. IMO all our OSes are so similar, PC software should almost all be cross-platform. Exceptions are mostly drivers and driver-adjacent code.
Windows and Linux actually feel pretty close these days, and I don’t generally feel any friction switching between them. But when I try to use a Mac it’s another story entirely. That OS just makes no sense to me - the keyboard shortcuts all seem to be insanely bad choices, just inconsistent with huge gaps and divergences from the other OSs. It feels so stuck in the 90s
This checks out. My leading mental model to explain this mismatch is that the critique has been from people who are expecting Mac idioms, which I can't speak to. Window and Linux GUI look/feel are fragmented as-is.
Keeping 3 separate native front ends in sync with custom visual components means you end up building a cross-platform UI. The only apps you can build without custom components are trivial ones.
All 3 have a way of embedding webviews. In my perhaps limited experience, all desire for custom visual components are either specious or for read-only presentation views. In my opinion all controls should be native, but if you ask for a fancy data presentation I have no qualms reaching for a webview.
So long as the web views provide for accessibility (and thus UI automation), this sounds perfectly reasonable for the majority of applications.
Speaking of which, my dream is an "HTML light" standard with a subset of functionality specifically designed for local UI use, ideally with lightweight non-browser engines supporting this standard shipping with all major OS platforms as shared system components.
We had browsers that ran on systems with 8 MB RAM, after all, and while it's not a fair comparison, there's no technical reason why a system with three orders of magnitude more RAM should struggle to run more than a handful of applications merely because they use HTML and JavaScript for rendering.
I am building such a lightweight browser engine: https://github.com/dioxuslabs/blitz. It targets most of HTML/CSS, but leaves out (or makes optinal) a lot of the extra stuff that browsers pull in). It also has the option to use Rust instead of JavaScript for the scripting layer.
Though 8 MB RAM is a non-starter when a single RGBA texture @4k is ~30Mb and modern system often require 2 or 3 for buffering. Somewhere around the 60MB to 100MB mark seems to be the base for modern setups, at least on macOS.
https://crates.io/crates/dioxus-native was released 3 months ago and does not have a link to GitHub, I do not think it can be considered as established project yet.
(I am the maintainer of dioxus native, and also posted the comment above)
So:
- The initial version was released over a year ago (3 month is the most recent patch release of the stable version).
- It is part of the Dioxus project (https://github.com/dioxuslabs/dioxus) which has been going since 2021 (but the other renderers are web/webview based).
- The native renderer (https://github.com/dioxuslabs/blitz) has been under development since December 2024 (building a whole new web engine is just a big project).
You're ultimately kind of right that it's not as established as 1-4 in the list. But I think it justifies it's place with the other frameworks lower down the list as one of the lesser-known frameworks that compete technically with those further up the list.
To the limit that any Winit-based app is. Which is to say it builds and runs, and there is basic touch and text input support. But system integration is pretty limited.
It's absolutely in good faith. There are two kinds of GUI framework in Rust:
- Those people have poured consistent time and effort into over a period of years
- Those people vibe code into existence in a couple of weeks and typically abandon after a few months.
Nobody wants to waste their time on the latter, so I am pointing people to the former. Yes, mine is one of them, but that doesn't make it bad faith, it just means I know what I'm talking about.
Yeah, have you tried to do anything in egui? I tried today a ComboBox, but I wanted one with filter input box, "X" icon to clear it, and automatic focus.
I've given up when the code reached 300 lines and was still buggy/not working.
egui is not mature. I'd prefer declarative approach, data binding, and styling. Therefore will skip egui.
i've built pretty complex stuff in egui. any modern agent will one-shot that component, so i'd say it's more just a lack of familiarity with the library.
Interesting to say given you know zero about the context which other's use it. Not everyone has the same needs everywhere, and blanket saying "No not ready" when you don't understand the context feels very premature, ironically.
> List is hand-picked list, ordered by crates.io downloads.
O_o
Just say it’s a hand picked list of ones you like and why.
Do you like them? Have you used them?
I found iced to be unreliable (couldn't reliably render basic widgets); slint overly relies on their DSL and honestly seemed to be moving away from rust; and GPUI felt sloppy. That was my personal “lets try rust gui” journey before I went; nope, guess we’re doing native ui and a shared rust core.
This is just a random list of stuff; I can't tell if you think they're all good (I dont) or just copy pasted chatgpt output.
For each one: why is it on the list? Do you like it? Why do you think, for example, slint, deserves to be on the list, when you dont even write the ui scripts in rust?
(Slint author here) Slint is written in Rust, and Rust API is at its core. That's not changing. What's wrong with the DSL? the UI is described in the DSL, the application logic in Rust. I wrote about why here: https://slint.dev/blog/domain-specific-language-vs-imperativ...
What gave you the impression we're moving away from Rust?
Look, bluntly, you can’t have your cake and eat it to. Either it’s a rust library or it’s not.
If you’re not writing your ui in rust, then even if parts of it are implemented in rust, it’s not a rust ui library any more than a js library like calls a c backend is a c library.
I really really wanted to like slint and absolutely did not.
> Domain Specific Languages like Slint offer a great alternative to traditional GUI toolkit APIs.
No they don’t.
If you can arbitrarily assert something so can I.
A DSL needs it clear the minimum bar of “why is this not just using a real programming language?”.
UI programming is tricky, but declarative approaches have almost universally failed, because there’s always some edge case logic that needs a full programming language to handle it.
The few UI DSLs that Ive seen work (eg. blueprint) exist a) as stand alone languages, and b) fill a niche that an existing language doesn’t.
What does your DSL do that is unique? Why was using js like qt quick not good enough? Why not just use rust?
The issue I have with it is you’ve never articulated why it exists.
Good DSLs like those implemented using clojure (1) are additions to the language that can natively be mixed into the existing language ecosystem.
You could have done the same in rust using proc macros; but instead you’ve chosen (as far as I can tell) to chase the non-rust UI market with a custom DSL.
Well.. you want an opinion? There you go. I don’t like slint, sorry. It’s not a rust UI library. It just happens to be implemented in rust, in my opinion.
It is one. Your app is a Rust program that depends on a crate. The UI compiles to Rust code, and we also have the `slint!` proc macro.
> there's always some edge case logic that needs a full programming language
Right, and that language is Rust. The DSL only describes the GUI. You operate it from Rust.
> Why was using js like qt quick not good enough?
QML was the inspiration. I worked on Qt and wrote QML bindings for Rust before (qmetaobject-rs). Slint is a new take on it, compiled ahead of time, no GC, strongly typed.
Yes, except you invented a new programming (1) language unnecessarily.
Whatever.
We'll have to agree to disagree.
If the programming language you write is not rust it is not a rust ui library.
Slint requires you to write your UI in slint. I havent used it much, but Ive used it enough to know that this:
> The DSL only describes the GUI
Is about as disingenuous as you can get.
Thats like saying that javascript only describes the GUI of a website, a backend rust website is really just a rust application. Really you're building in rust. React is really a rust UI library at heart. <—- obviously BS.
>A DSL needs it clear the minimum bar of “why is this not just using a real programming language?”.
No, a DSL only needs to be better than the language itself to write a layout in. UI is a whole different beast than anything else, where deep nesting is common, layouts flow in many ways, and more. Rust is simply not appropriate to make that pleasant.
Take a simple layout like you'd declare it in Kotlin using Compose:
What a delicious piece of trash. Since you've said no macros, you're carrying an additional variable everywhere (Composer is a Compose system, but you have the same thing in every UI library that does the same. Call it Context, whatever you want). You have shitty lambdas that need to pass the scope too (because Modifier.weight() only works on a ColumnScope). You have no named parameters, and the only way you would would be crap like having a ButtonProps struct. You have impl Fn() + 'static written in your code. And then if you start to want to do some actual work like "clicking on the button increases a counter", you're suddenly spamming Arc::clone, |move| Rc's everywhere in your code because Rust is simply not a good language for UIs.
(And if you want to go the old school way of simply managing yourself a widget tree, good luck, not only is it always full of bugs, it's also an unmaintainable garbage fire.)
Clojure is not a good language for DSLs either, and the post you've linked is just jerking itself off saying "look i can convert some clojure into the exact bash equivalent by only changing one thing" when it's the exact reason why every single clojure project ends up reimplementing the wheel twelves times and is a piece of shit unmaintainable kludge of whatever code the local genius wanted to commit in this morning. Good languages have constraints.
So yes: DSLs _always_ offer a better alternative. QML is a good DSL, and using Javascript is not the reason why.
Slint is proprietary. Given that AI makes it so easy to spec out and build even entire GUI frameworks, why would you even go with proprietary anymore? And why doesn't the article showcase a full-fledged set of UI components?
> AI makes it so easy to spec out and build even entire GUI frameworks
When a vibe coded gui framework becomes so good that it simply cannot be ignored, I'll believe this can work. Until then, all I've seen is half-baked disposable slop that looks really good on paper.
I tried using it and yeah, GPUI felt very sloppy. Something about that lack of documentation + having to install it from some subdirectory in a giant monorepo + Tailwind-based API...
And the recommended component library for it (GPUI Kit) seems to have been 100% Clauded, down to the website and README.
I find this line pretty sad actually, what if someone wants to contribute code, written by hand? What if some beginner finds this project interesting and wants to invest own time into it?
Or human is completely removed from the development whatsoever..
> I find this line pretty sad actually, what if someone wants to contribute code, written by hand? What if some beginner finds this project interesting and wants to invest own time into it?
Then they would be better off contributing to a project that welcomes them.
> what if someone wants to contribute code, written by hand?
It's up to the maintainer. Sometimes it's just easier to listen to what's needed and do it the way you know and are efficient with than to review someone else's code.
> What if some beginner finds this project interesting and wants to invest own time into it?
There's nothing stopping them. They can even publish it in a fork.
Yep. There's other projects that have a "we want your ideas, but not your code" policy (like SQLite and Lua), but the "just tell your agent to tell our agent what to do" framing makes me depressed.
I did the same for a vibecoded project [0] but I would never do this for a human-written project. Simply put, if most contributions are similarly vibecoded and/or they will be reviewed/treated as such, then how is a PR/review from an unaffiliated agent any better than one managed by the project curator. Of course that human curation still needs to occur.
This is a natural progression (only on these types of projects). We accepted contributions because it actually helped and they were difficult and time consuming. When that is no longer the case, contributions are a burden, the actual problem/idea is the real value, hence the request to open the issue.
Won’t this just lead to bloatware in the long run? Part of creating a product is knowing what to say no to. And I’ve found my customers’ ideas for how to improve my products aren’t always the best way to implement the feature they want (or it would create issues for other customers who use it differently).
It sounds like a black hat penetration tester's nirvana. All you have to do is open the right issue to trick the model into installing the right security vulnerability or backdoor, or better yet, a series of small security vulnerabilities that can be chained to create a tailor-made exploit. It's practically a hacker's choose-your-own adventure.
I suspect they'd be manually filtering which issues/features their agents attempt to fix/implement. Otherwise you end up with all sorts of features that simply make no sense for the project.
The approach is at least better than accepting slop PRs that could have backdoors injected into them.
My main concern with this would be that for a library in particular I need a stable API and behavior (Hyrum's law). I do not know to what extent a fully autonomous agentic approach can ensure that. Note: I don't see a problem with preferring issues over pull requests (many of which would be poorly coded slop), just fully automating the handling.
Also a bit wild to assume that no person will just create an issue manually. This is not something I'd normally use an agent for.
Headless part is neat, but agents can already drive apps and take screenshots. As a side note, I have agent driving android tv using wireless adb and hdmi capture card + mpv rpc, its fun to watch.
Has GPUI development even picked up since the Zed team gave up on it? The GPUI website still links directly to the Zed repo's subfolder. I can't tell if there's even one coherent GPUI project any more
Looks interesting, especially the headless part. Been building various apps lately for ios/ipados/macos for personal use and I would love something like this that would be truly cross platform. Xcode with agent use has been really nice to work with, and t3.code support for emulators has been amazing to use.
What is benefit of GPU-rendered UI? In regular 2d apps where I can select enable/disable GPU rendering, disabling doesn't make app feel slower, but it drastically reduces RAM and VRAM usage (VRAM is the one I care about, as I run local models). Why so many UI frameworks brag that they are GPU-rendered?
Other people have different hardware and different goals. A year or so ago I worked on a Linux laptop that was dog-slow. If I didn't enable GPU-rendering for the UI, it competed for the very limited CPU.
Using less power is generally the main benefit. On lower end hardware you may also notice a performance difference, depending on what the UI is trying to display.
Sorry, what? I feel like I've studied the Rust UI ecosystem pretty well, and the examples look nice, but if I've learned anything it's that "native" and "GPU-rendered" are oxymoronic.
Likely the fonts will be fuzzy on various platforms, accessibility will be under-baked and it will land in the bucket with every other UI framework depending on winit. I like the personalities at anomaly, but I'm quite confused about what's even driving a decision to build something like this versus contributing to egui, GPUI, Iced, etc.
It's definitely possible to do sharp fonts in the Rust GUI ecosystem (although you certainly won't get it out of the box). With the native text libraries if you want to (both Servo, Zed/GPUI, and anything using Skia do this), or emulated with Skrifa + Vello.
Yeah. Presumably "native" here just means "not Electron", which is the sales pitch for most AI-generated Rust libraries these days. ("Tell your agent to rewrite your Electron app into Rust~! :rocket emoji:")
When I made my ow GPU-renderered framework I found that it was possible to render the entire UI in one call/shader to the UI. All primitives and styles can be passed as a updatable data blob that the single GPU shader handles in one call. Do most of the GPU-rendered frameworks do it this way?
It has some tradeoffs to consider but seems quite good overall.
An approach I've found useful, albeit for a DSL that ships a binary for execution, is to give a way for the LLM agent to get a high-level topic list so it can drill down all the way to specific language/API implementation details.
Perhaps with this project the author could make a website that does the same?
It would be fun to port some apps over to this, I'm worried at the speed it moves, It would be hard to settle on a commit. I'd rather fast updates over slow, but I feel like I'd have very little trust on this between updates, especially how many things could be broken after updating.
Changing times. Nowadays a lot of software UIs are developed by people with a web UI background. Those people won’t learn the OS-native UIs because that would mean they’d give up on their existing knowledge. Because of that native means “not running in an embedded web browser” to many nowadays.
I have the same annoyance. It's continually maddening to see "native" plastered everywhere only for it to be some non-native junk. I miss when native meant something like Qt.
Qt is an interesting case, because it doesn't use the native platform's widget code*, but does a good job of looking and behaving as though it does. That's usually close enough for me.
Various other toolkits have tried this approach, but unfortunately, I'm not aware of any others that succeed. Common deficiencies include keyboard navigation and text rendering.
*(Except on Qt-based desktops like KDE Plasma, of course.)
I've been thinking a lot about the term "native" as I come from mobile. When writing a core in Rust (which I like to do), and then layering on the operating system's UI SDK components per platform (which I also like to do), what is native and what isn't, especially when you throw in React Native to the discussion?
I like your definition quite a bit, but I need another word for, "code that doesn't need a runtime to execute."
I ended up using "experience layer" to describe the SDK components.
Native often means "not a wrapper around a webview".
If you define it as "using the widgets provided by the operating system", then "native" is by definition incompatible with "cross-platform." And what does that mean on Linux, where the operating system doesn't provide widgets? Are gtk and Qt not native?
When discussing GUI toolkits, "native" should be understood to mean "native to the host's graphical environment".
"Native to the OS" might or might not be equivalent, depending on the OS and what one considers "OS" to mean. (Does it mean a kernel? A desktop distro? Something else?) Because of this ambiguity, it's not a very practical way to approach the discussion. Different people attach different meanings to that phrase.
Some frameworks are native to Qt. Others are native to Gtk. Practically none are native to Linux. ;)
I don't think "cross-platform" is incompatible with "native". It has been achieved more than once using toolkit wrappers, usually selected at build time.
I was thinking "Builds and tests with a fast-moving Rust code base like this must be painful", then I noticed the total absence of tests: https://github.com/anomalyco/rune/commits/dev/
You're not shifting left unless you guarantee local tests always run, faithfully to production. That rarely happens. Local testing should be supplementary. We use https://hk.jdx.dev/
We do ensure this, requiring signed proof, running in containers that would be identical to github runners (more or less). Now, this could be spoofed by an engineer, but we operate in a high trust environment
This is what a vibe coded UI framework looks like.
Have a read of the clean documentation that they never wrote or read. [0]
All the clean code, architecture principles thrown out of the window in favour of hundreds of code smells, anti-patterns, zero tests, and tons of unmaintainable slop.
Damn, this README is more of a DONTREADME. Even the root README is for agents, not people. The more I see stuff like this, the more I think about becoming a welder or a carpenter...
The site is wild, but the little triangles in the bottom right corners of each window don't work properly on chrome desktop in windows 11. They aren't clickable, you can only resize the windows horizontally. Which seems weird considering how polished the rest of it looks.
It's a fun tech demo, egui isn't meant to make websites. It's primarily for integration into games/other real-time-3D-rendered applications, and secondarily for GUI applications via eframe.
But I agree, I think they would be better served by making a normal website and linking to the demo prominently (For comparison, see iced's website https://iced.rs, which is great IMO)
If you're interested in a GPU-rendered Rust UI framework, then maybe skip this vibe coded project, and check out some of following established projects:
List is hand-picked list, ordered by crates.io downloads. I had an LLM fetch the download counts and links. Webview based UI like Tauri and Dioxus Desktop are excluded. As are bindings to native toolkits and GTK.IMO, the top GUI framework crates for Rust are windows or native-windows-gui, objc2 or icrate for MacOS and gtk4-rs for Linux only. Actually for MacOS / iOS I'd use uniffi to embed the rust core in a SwiftUI app.
In 2026 IMO it's much better to use an LLM to keep 3 separate native front ends in sync than it is to try and use any sort of cross platform UI.
Could you please explain why? For example: Is it colors? A je-ne-sais-quoi? Widget rounding size and fonts? Performance reasons? Keyboard shortcuts? Do you really find it's easier to maintain 3 separate frontends using an LLM than using EGUI, GPUI, QT etc?
I have seen this suggestion several times recently regarding GUI framework threads on HN in the past week (There has been a surge!), but they are always described in the way you did: With no explanation of why. Just an assertion that native UI kits (of which you need a separate one for each OS family) are superior; cross-platform kids are an "inferior experience" etc. I have asked at 3 times and received no answer. I say this as someone who uses both Windows and Linux regularly, and find they are functionally equivalent once you have an application launched. There are ABI differences, driver differences, file system differences, etc which need to be smoothed over with feature gates for certain application functionality, if you're using certain functionality.
I want my applications to have the required functionality, run fast, and have a good UI. I don't care if the widgets look the same as on my other applications or the ones built in to the OS; this isn't even a thing because there is so little standardization broadly. Maybe on Macs it's standardized and cross-platform kits look out of place?
The proposed approach of "Use LLMs to vibe-code a system of 3 native kits" has cons to weigh. Or making your program Windows only or w/e for a look-and-feel reason or whatever it is has cons too. IMO all our OSes are so similar, PC software should almost all be cross-platform. Exceptions are mostly drivers and driver-adjacent code.
Windows and Linux actually feel pretty close these days, and I don’t generally feel any friction switching between them. But when I try to use a Mac it’s another story entirely. That OS just makes no sense to me - the keyboard shortcuts all seem to be insanely bad choices, just inconsistent with huge gaps and divergences from the other OSs. It feels so stuck in the 90s
This checks out. My leading mental model to explain this mismatch is that the critique has been from people who are expecting Mac idioms, which I can't speak to. Window and Linux GUI look/feel are fragmented as-is.
Keeping 3 separate native front ends in sync with custom visual components means you end up building a cross-platform UI. The only apps you can build without custom components are trivial ones.
All 3 have a way of embedding webviews. In my perhaps limited experience, all desire for custom visual components are either specious or for read-only presentation views. In my opinion all controls should be native, but if you ask for a fancy data presentation I have no qualms reaching for a webview.
So long as the web views provide for accessibility (and thus UI automation), this sounds perfectly reasonable for the majority of applications.
Speaking of which, my dream is an "HTML light" standard with a subset of functionality specifically designed for local UI use, ideally with lightweight non-browser engines supporting this standard shipping with all major OS platforms as shared system components.
We had browsers that ran on systems with 8 MB RAM, after all, and while it's not a fair comparison, there's no technical reason why a system with three orders of magnitude more RAM should struggle to run more than a handful of applications merely because they use HTML and JavaScript for rendering.
I am building such a lightweight browser engine: https://github.com/dioxuslabs/blitz. It targets most of HTML/CSS, but leaves out (or makes optinal) a lot of the extra stuff that browsers pull in). It also has the option to use Rust instead of JavaScript for the scripting layer.
Though 8 MB RAM is a non-starter when a single RGBA texture @4k is ~30Mb and modern system often require 2 or 3 for buffering. Somewhere around the 60MB to 100MB mark seems to be the base for modern setups, at least on macOS.
> perhaps limited experience
New rule: Programmers with limited UI experience (that includes myself) should abstain from weighing in on what UI designers and programmers need.
An advantage of this approach is that everyone's screen readers and other accessibility tools actually work with your app.
There's also relm4 which builds a Elm-like paradigm on top of gtk4-rs.
rather than gtk4-rs maybe try relm4
https://crates.io/crates/dioxus-native was released 3 months ago and does not have a link to GitHub, I do not think it can be considered as established project yet.
(I am the maintainer of dioxus native, and also posted the comment above)
So:
- The initial version was released over a year ago (3 month is the most recent patch release of the stable version).
- It is part of the Dioxus project (https://github.com/dioxuslabs/dioxus) which has been going since 2021 (but the other renderers are web/webview based).
- The native renderer (https://github.com/dioxuslabs/blitz) has been under development since December 2024 (building a whole new web engine is just a big project).
You're ultimately kind of right that it's not as established as 1-4 in the list. But I think it justifies it's place with the other frameworks lower down the list as one of the lesser-known frameworks that compete technically with those further up the list.
Is dioxus native usable in android already?
To the limit that any Winit-based app is. Which is to say it builds and runs, and there is basic touch and text input support. But system integration is pretty limited.
[flagged]
It's absolutely in good faith. There are two kinds of GUI framework in Rust:
- Those people have poured consistent time and effort into over a period of years
- Those people vibe code into existence in a couple of weeks and typically abandon after a few months.
Nobody wants to waste their time on the latter, so I am pointing people to the former. Yes, mine is one of them, but that doesn't make it bad faith, it just means I know what I'm talking about.
You've the patience of a saint to respond so politely to abrasiveness
And thanks for sharing the list and saving me from clicking on yet more half baked vibe spam!
Yeah, have you tried to do anything in egui? I tried today a ComboBox, but I wanted one with filter input box, "X" icon to clear it, and automatic focus.
I've given up when the code reached 300 lines and was still buggy/not working.
egui is not mature. I'd prefer declarative approach, data binding, and styling. Therefore will skip egui.
i've built pretty complex stuff in egui. any modern agent will one-shot that component, so i'd say it's more just a lack of familiarity with the library.
Stick to Qt, none of those solutions are mature enough for actual production use.
Lots of companies use them in production.
Interesting to say given you know zero about the context which other's use it. Not everyone has the same needs everywhere, and blanket saying "No not ready" when you don't understand the context feels very premature, ironically.
> List is hand-picked list, ordered by crates.io downloads.
O_o
Just say it’s a hand picked list of ones you like and why.
Do you like them? Have you used them?
I found iced to be unreliable (couldn't reliably render basic widgets); slint overly relies on their DSL and honestly seemed to be moving away from rust; and GPUI felt sloppy. That was my personal “lets try rust gui” journey before I went; nope, guess we’re doing native ui and a shared rust core.
This is just a random list of stuff; I can't tell if you think they're all good (I dont) or just copy pasted chatgpt output.
For each one: why is it on the list? Do you like it? Why do you think, for example, slint, deserves to be on the list, when you dont even write the ui scripts in rust?
(Slint author here) Slint is written in Rust, and Rust API is at its core. That's not changing. What's wrong with the DSL? the UI is described in the DSL, the application logic in Rust. I wrote about why here: https://slint.dev/blog/domain-specific-language-vs-imperativ...
What gave you the impression we're moving away from Rust?
The website developer docs.
Look, bluntly, you can’t have your cake and eat it to. Either it’s a rust library or it’s not.
If you’re not writing your ui in rust, then even if parts of it are implemented in rust, it’s not a rust ui library any more than a js library like calls a c backend is a c library.
I really really wanted to like slint and absolutely did not.
> Domain Specific Languages like Slint offer a great alternative to traditional GUI toolkit APIs.
No they don’t.
If you can arbitrarily assert something so can I.
A DSL needs it clear the minimum bar of “why is this not just using a real programming language?”.
UI programming is tricky, but declarative approaches have almost universally failed, because there’s always some edge case logic that needs a full programming language to handle it.
The few UI DSLs that Ive seen work (eg. blueprint) exist a) as stand alone languages, and b) fill a niche that an existing language doesn’t.
What does your DSL do that is unique? Why was using js like qt quick not good enough? Why not just use rust?
The issue I have with it is you’ve never articulated why it exists.
Good DSLs like those implemented using clojure (1) are additions to the language that can natively be mixed into the existing language ecosystem.
You could have done the same in rust using proc macros; but instead you’ve chosen (as far as I can tell) to chase the non-rust UI market with a custom DSL.
Well.. you want an opinion? There you go. I don’t like slint, sorry. It’s not a rust UI library. It just happens to be implemented in rust, in my opinion.
(1) - https://clojure-doc.org/articles/cookbooks/growing_a_dsl_wit...
> Either it's a rust library or it's not.
It is one. Your app is a Rust program that depends on a crate. The UI compiles to Rust code, and we also have the `slint!` proc macro.
> there's always some edge case logic that needs a full programming language
Right, and that language is Rust. The DSL only describes the GUI. You operate it from Rust.
> Why was using js like qt quick not good enough?
QML was the inspiration. I worked on Qt and wrote QML bindings for Rust before (qmetaobject-rs). Slint is a new take on it, compiled ahead of time, no GC, strongly typed.
> The UI compiles to Rust
Right, so not rust.
Languages that compile to c are not c.
Languages that compile to rust are not rust.
> QML was the inspiration
Yes, except you invented a new programming (1) language unnecessarily.
Whatever.
We'll have to agree to disagree.
If the programming language you write is not rust it is not a rust ui library.
Slint requires you to write your UI in slint. I havent used it much, but Ive used it enough to know that this:
> The DSL only describes the GUI
Is about as disingenuous as you can get.
Thats like saying that javascript only describes the GUI of a website, a backend rust website is really just a rust application. Really you're building in rust. React is really a rust UI library at heart. <—- obviously BS.
(1) - https://docs.slint.dev/latest/docs/slint/guide/language/conc...
>A DSL needs it clear the minimum bar of “why is this not just using a real programming language?”.
No, a DSL only needs to be better than the language itself to write a layout in. UI is a whole different beast than anything else, where deep nesting is common, layouts flow in many ways, and more. Rust is simply not appropriate to make that pleasant.
Take a simple layout like you'd declare it in Kotlin using Compose:
Kotlin naturally has trailing lambdas, method references, has the advantage of being a GC'd language so memory management is out the window.In pure rust ?
}What a delicious piece of trash. Since you've said no macros, you're carrying an additional variable everywhere (Composer is a Compose system, but you have the same thing in every UI library that does the same. Call it Context, whatever you want). You have shitty lambdas that need to pass the scope too (because Modifier.weight() only works on a ColumnScope). You have no named parameters, and the only way you would would be crap like having a ButtonProps struct. You have impl Fn() + 'static written in your code. And then if you start to want to do some actual work like "clicking on the button increases a counter", you're suddenly spamming Arc::clone, |move| Rc's everywhere in your code because Rust is simply not a good language for UIs.
(And if you want to go the old school way of simply managing yourself a widget tree, good luck, not only is it always full of bugs, it's also an unmaintainable garbage fire.)
Clojure is not a good language for DSLs either, and the post you've linked is just jerking itself off saying "look i can convert some clojure into the exact bash equivalent by only changing one thing" when it's the exact reason why every single clojure project ends up reimplementing the wheel twelves times and is a piece of shit unmaintainable kludge of whatever code the local genius wanted to commit in this morning. Good languages have constraints.
So yes: DSLs _always_ offer a better alternative. QML is a good DSL, and using Javascript is not the reason why.
It seems like self promotion, but in a smart way.
https://news.ycombinator.com/item?id=50394569#50398826
Slint is proprietary. Given that AI makes it so easy to spec out and build even entire GUI frameworks, why would you even go with proprietary anymore? And why doesn't the article showcase a full-fledged set of UI components?
I might be wrong, but I believe Slint has qt-style dual-licensing and provides AGPL version for GPL projects.
I assume you make an open source project giving the critics about proprietary nature, so it shouldn't be a problem.
[dead]
> AI makes it so easy to spec out and build even entire GUI frameworks
When a vibe coded gui framework becomes so good that it simply cannot be ignored, I'll believe this can work. Until then, all I've seen is half-baked disposable slop that looks really good on paper.
most downloaded is a poor metric
Luckily GPUI isn't vibe coded at all but a mature and well thought-out project.. /s
I tried using it and yeah, GPUI felt very sloppy. Something about that lack of documentation + having to install it from some subdirectory in a giant monorepo + Tailwind-based API...
And the recommended component library for it (GPUI Kit) seems to have been 100% Clauded, down to the website and README.
the component library is gpui-component which I think is a too old of a project to have been built primarily by AI
gpui-kit is meant to solve your second point: installing it from crates.io rather some unrelated monorepo
it doesn't matter if gpui-kit is vibe coded because it's just upstream gpui, repackaged
Hmm, I see, thanks for the correction
Brutal and based
Sort of a digression, but it's the first time I've seen something like this:
Pretty interesting approach, compared to receiving a zillion potentially sloppy PRs. Open source in the age of LLMs.. ("agent source"?)I find this line pretty sad actually, what if someone wants to contribute code, written by hand? What if some beginner finds this project interesting and wants to invest own time into it?
Or human is completely removed from the development whatsoever..
> I find this line pretty sad actually, what if someone wants to contribute code, written by hand? What if some beginner finds this project interesting and wants to invest own time into it?
Then they would be better off contributing to a project that welcomes them.
While I sympathize I think we all know a majority of contributions would not be hand written. This is optimizing for the reality we're in.
You could fork and reference it in the issue if you still wanted to contribute.
> what if someone wants to contribute code, written by hand?
It's up to the maintainer. Sometimes it's just easier to listen to what's needed and do it the way you know and are efficient with than to review someone else's code.
> What if some beginner finds this project interesting and wants to invest own time into it?
There's nothing stopping them. They can even publish it in a fork.
Why would any beginner want to contribute or invest a large amount of time where he doesn't trust a maintainer or their processes?
Yep. There's other projects that have a "we want your ideas, but not your code" policy (like SQLite and Lua), but the "just tell your agent to tell our agent what to do" framing makes me depressed.
Why would you contribute code written by hand in 2026?
Just take your hand written code and have it send it as the request to the AI.
Why would you want to contribute thoughtfully written code to a slop project?
Those days are over
I did the same for a vibecoded project [0] but I would never do this for a human-written project. Simply put, if most contributions are similarly vibecoded and/or they will be reviewed/treated as such, then how is a PR/review from an unaffiliated agent any better than one managed by the project curator. Of course that human curation still needs to occur.
This is a natural progression (only on these types of projects). We accepted contributions because it actually helped and they were difficult and time consuming. When that is no longer the case, contributions are a burden, the actual problem/idea is the real value, hence the request to open the issue.
0 - https://github.com/cretz/vitaslop
Won’t this just lead to bloatware in the long run? Part of creating a product is knowing what to say no to. And I’ve found my customers’ ideas for how to improve my products aren’t always the best way to implement the feature they want (or it would create issues for other customers who use it differently).
They never said they'd merge in every idea.
I had a Nix issue. Agents fixed it in 5 min.
Of course, one could conclude that another agents screwed up before, still was a good experience.
It sounds like a black hat penetration tester's nirvana. All you have to do is open the right issue to trick the model into installing the right security vulnerability or backdoor, or better yet, a series of small security vulnerabilities that can be chained to create a tailor-made exploit. It's practically a hacker's choose-your-own adventure.
I am not sure about that.
Which gate is easier to maintain?
1. Check issues for malicious intent
2. Check PR for malicious intent.
I think in PR requests it is easier to introduce purposeful bugs or obfuscated code than it is to hide them in issues.
So I think gating on issues is easier and more secure.
I suspect they'd be manually filtering which issues/features their agents attempt to fix/implement. Otherwise you end up with all sorts of features that simply make no sense for the project.
The approach is at least better than accepting slop PRs that could have backdoors injected into them.
That seems a lot harder than if they accepted PRs like everyone else
Makes this (not a real) job posting seem all the more funny/relevant:
https://lovro-bikic.github.io/software-line-specialist/
My main concern with this would be that for a library in particular I need a stable API and behavior (Hyrum's law). I do not know to what extent a fully autonomous agentic approach can ensure that. Note: I don't see a problem with preferring issues over pull requests (many of which would be poorly coded slop), just fully automating the handling.
Also a bit wild to assume that no person will just create an issue manually. This is not something I'd normally use an agent for.
> Every app can run headless, so an agent can render to PNG, dump the element tree and drive it with scripted input.
This is cool. I hope SwiftUI / UIKit borrow this idea for native mac apps.
You can do the same thing with swiftui. The surface you render to doesn't have to be visible at all. And the tree has nice introspection available.
Headless part is neat, but agents can already drive apps and take screenshots. As a side note, I have agent driving android tv using wireless adb and hdmi capture card + mpv rpc, its fun to watch.
How should I think about this, compared to GPUI (https://gpui.rs)? What are pros and cons?
Dax on Twitter: "we just couldn't get gpui to look good enough"
Has GPUI development even picked up since the Zed team gave up on it? The GPUI website still links directly to the Zed repo's subfolder. I can't tell if there's even one coherent GPUI project any more
Does this have:
- Accessibility? E.g. Screen reader support?
- Alternative inputs? Full keyboard support?
- Full internationalization, including right-to-left and diacritics?
What happens when no GPU is available?
Just curious as this matters for it to be a serious library and not a proof of concept.
The most common rust UI framework I’m aware of, iced, completely fails on these metrics afaik.
Egui is an order of magnitude more common than iced
Totally fair and you’re right. I did not realize the size of the gap there until now.
Looks interesting, especially the headless part. Been building various apps lately for ios/ipados/macos for personal use and I would love something like this that would be truly cross platform. Xcode with agent use has been really nice to work with, and t3.code support for emulators has been amazing to use.
What is benefit of GPU-rendered UI? In regular 2d apps where I can select enable/disable GPU rendering, disabling doesn't make app feel slower, but it drastically reduces RAM and VRAM usage (VRAM is the one I care about, as I run local models). Why so many UI frameworks brag that they are GPU-rendered?
Well, for one, it usually is much more energy-efficient: longer battery life, cooler computers, and more responsive under heavy (CPU) load.
Other people have different hardware and different goals. A year or so ago I worked on a Linux laptop that was dog-slow. If I didn't enable GPU-rendering for the UI, it competed for the very limited CPU.
Using less power is generally the main benefit. On lower end hardware you may also notice a performance difference, depending on what the UI is trying to display.
composition with transparencies is the main one
> native GPU-rendered Rust UI
Sorry, what? I feel like I've studied the Rust UI ecosystem pretty well, and the examples look nice, but if I've learned anything it's that "native" and "GPU-rendered" are oxymoronic.
Likely the fonts will be fuzzy on various platforms, accessibility will be under-baked and it will land in the bucket with every other UI framework depending on winit. I like the personalities at anomaly, but I'm quite confused about what's even driving a decision to build something like this versus contributing to egui, GPUI, Iced, etc.
It's definitely possible to do sharp fonts in the Rust GUI ecosystem (although you certainly won't get it out of the box). With the native text libraries if you want to (both Servo, Zed/GPUI, and anything using Skia do this), or emulated with Skrifa + Vello.
But I agree with the reset
Yeah. Presumably "native" here just means "not Electron", which is the sales pitch for most AI-generated Rust libraries these days. ("Tell your agent to rewrite your Electron app into Rust~! :rocket emoji:")
When I made my ow GPU-renderered framework I found that it was possible to render the entire UI in one call/shader to the UI. All primitives and styles can be passed as a updatable data blob that the single GPU shader handles in one call. Do most of the GPU-rendered frameworks do it this way?
It has some tradeoffs to consider but seems quite good overall.
Re: Use it with your agent
An approach I've found useful, albeit for a DSL that ships a binary for execution, is to give a way for the LLM agent to get a high-level topic list so it can drill down all the way to specific language/API implementation details.
Perhaps with this project the author could make a website that does the same?
Broadly: In what circumstances, use cases, preferences etc would I use this instead of EGUI or GPUI?
The double-edged sword of choice!
I'd like to know this too. I'm building a egui app and it's fantastic. I have tons of custom drawing and stuff though
It would be fun to port some apps over to this, I'm worried at the speed it moves, It would be hard to settle on a commit. I'd rather fast updates over slow, but I feel like I'd have very little trust on this between updates, especially how many things could be broken after updating.
Rune, the rust ui framework, not to be confused with Rune, an embeddable dynamic programming language for Rust
Not to be confused with Rune, the development environment [0].
[0]: https://rune.build/
Is this related to https://rune.build which was also developing their own rendering layer?
It isn’t. Rune is written in Go, and completely unrelated.
What does "native" mean to these people. Native UI means using the widgets provided by the operating system. This is not that.
Changing times. Nowadays a lot of software UIs are developed by people with a web UI background. Those people won’t learn the OS-native UIs because that would mean they’d give up on their existing knowledge. Because of that native means “not running in an embedded web browser” to many nowadays.
I have the same annoyance. It's continually maddening to see "native" plastered everywhere only for it to be some non-native junk. I miss when native meant something like Qt.
Qt is an interesting case, because it doesn't use the native platform's widget code*, but does a good job of looking and behaving as though it does. That's usually close enough for me.
Various other toolkits have tried this approach, but unfortunately, I'm not aware of any others that succeed. Common deficiencies include keyboard navigation and text rendering.
*(Except on Qt-based desktops like KDE Plasma, of course.)
I've been thinking a lot about the term "native" as I come from mobile. When writing a core in Rust (which I like to do), and then layering on the operating system's UI SDK components per platform (which I also like to do), what is native and what isn't, especially when you throw in React Native to the discussion?
I like your definition quite a bit, but I need another word for, "code that doesn't need a runtime to execute."
I ended up using "experience layer" to describe the SDK components.
Native often means "not a wrapper around a webview".
If you define it as "using the widgets provided by the operating system", then "native" is by definition incompatible with "cross-platform." And what does that mean on Linux, where the operating system doesn't provide widgets? Are gtk and Qt not native?
Adding to this...
When discussing GUI toolkits, "native" should be understood to mean "native to the host's graphical environment".
"Native to the OS" might or might not be equivalent, depending on the OS and what one considers "OS" to mean. (Does it mean a kernel? A desktop distro? Something else?) Because of this ambiguity, it's not a very practical way to approach the discussion. Different people attach different meanings to that phrase.
Some frameworks are native to Qt. Others are native to Gtk. Practically none are native to Linux. ;)
I don't think "cross-platform" is incompatible with "native". It has been achieved more than once using toolkit wrappers, usually selected at build time.
The dynamic lighting setup is pretty cool. Not sure how practical it is for most applications but cool.
But this syntax – egads man! It literally hurts my brain trying to parse it:
Maybe I'm getting too old but I'd prefer good old Perl 5 linenoise.So it's a UI framework by agents, for agents?
why are we giving more accessibility to agents than to like disabled human users?
I wonder whether that results in better accessibility for disabled people in the end because agents can control UIs for them.
I was thinking "Builds and tests with a fast-moving Rust code base like this must be painful", then I noticed the total absence of tests: https://github.com/anomalyco/rune/commits/dev/
there are tests, no?
e.g. https://github.com/anomalyco/rune/tree/dev/crates/rune-kit/t...
Indeed. But why not run the tests in CI when merging to master?
Where I work, we've moved CI "left", all tests are run on the developers machine before merging
You're not shifting left unless you guarantee local tests always run, faithfully to production. That rarely happens. Local testing should be supplementary. We use https://hk.jdx.dev/
We do ensure this, requiring signed proof, running in containers that would be identical to github runners (more or less). Now, this could be spoofed by an engineer, but we operate in a high trust environment
This is interesting. Are you using an available product for managing these signatures, or did you write your own?
we built workflows using swamp https://swamp-club.com/
They ain't running in CI.
This is from the same guys that thought building a coding agent harness with "Bun" was a good idea
This is what a vibe coded UI framework looks like.
Have a read of the clean documentation that they never wrote or read. [0]
All the clean code, architecture principles thrown out of the window in favour of hundreds of code smells, anti-patterns, zero tests, and tons of unmaintainable slop.
[0] https://github.com/anomalyco/rune/blob/dev/crates/rune/READM...
Wait, zero tests? It is super cheap to write tests these days. It is how you gate agent generated code from destroying production.
They have tests, this person is just wrong.
What are you talking about? They definitely have tests.
Damn, this README is more of a DONTREADME. Even the root README is for agents, not people. The more I see stuff like this, the more I think about becoming a welder or a carpenter...
Why do you say 0 tests? Are the other statements similarly precise?
You're not kidding - that README is not readable.
I don't thinks its intended to be read by humans
[dead]
Another option is Crux, which lets use actual native UI:
https://redbadger.github.io/crux
> and the web,
And no live examples...
Another Vibe coded slop which will probably be not maintained after 3-4 weeks.
...what does this do? Is it just a vibecoded version of https://www.egui.rs/
The site is wild, but the little triangles in the bottom right corners of each window don't work properly on chrome desktop in windows 11. They aren't clickable, you can only resize the windows horizontally. Which seems weird considering how polished the rest of it looks.
It presumably powers OpenCode, the agent harness.
It doesn't, that's https://github.com/anomalyco/opentui.
Apparently the plan is to move the desktop from Electron to Rune: https://github.com/anomalyco/rune/blob/dev/PLAN.md
it doesn’t look immediate mode to me?
The website for https://www.egui.rs sort of sucks, it took around 10 seconds to load and initialize for some reason.
It's a fun tech demo, egui isn't meant to make websites. It's primarily for integration into games/other real-time-3D-rendered applications, and secondarily for GUI applications via eframe.
But I agree, I think they would be better served by making a normal website and linking to the demo prominently (For comparison, see iced's website https://iced.rs, which is great IMO)
> For comparison, see iced's website https://iced.rs, which is great IMO
This isn't much better. It's super laggy with high CPU usage.
It doesn't even load if you don't have WebGL2.
[flagged]
[dead]