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.
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..
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 us what our agents should do" framing makes me depressed.
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.
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.
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?
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.
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.
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.
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:")
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.
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?
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
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)
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...
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.
Or human is completely removed from the development whatsoever..
You could fork and reference it in the issue if you still wanted to contribute.
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.
The approach is at least better than accepting slop PRs that could have backdoors injected into them.
This is cool. I hope SwiftUI / UIKit borrow this idea for native mac apps.
- 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 double-edged sword of choice!
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.
But I agree with the reset
[0]: https://rune.build/
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.
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?
e.g. https://github.com/anomalyco/rune/tree/dev/crates/rune-kit/t...
https://redbadger.github.io/crux
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)
This isn't much better. It's super laggy with high CPU usage.
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...