Rune: A native GPU-rendered Rust UI framework for macOS, Windows, Linux and web
github.com
github.com
Rust-native GUI frameworks (by crates.io downloads):
1. egui (30.3M total / 9.2M last 90 days)
https://crates.io/crates/egui
2. Iced (3.2M / 770k)
https://crates.io/crates/iced
3. Slint (2.4M / 955k)
https://crates.io/crates/slint
4. GPUI (447k / 255k)
https://crates.io/crates/gpui
5. Dioxus Native (181k / 26k)
https://crates.io/crates/dioxus-native
6. Freya (49k / 12k)
https://crates.io/crates/freya
7. Floem (45k / 15k)
https://crates.io/crates/floem
8. Vizia (7k / 700)
https://crates.io/crates/vizia
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.
New rule: Programmers with limited UI experience (that includes myself) should abstain from weighing in on what UI designers and programmers need.
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.
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.
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.
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.
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.
And the recommended component library for it (GPUI Kit) seems to have been 100% Clauded, down to the website and README.
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
I assume you make an open source project giving the critics about proprietary nature, so it shouldn't be a problem.
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.
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?
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.
(1) - https://clojure-doc.org/articles/cookbooks/growing_a_dsl_wit...
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.
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...
> We don't take pull requests. Have your agent open
> an issue describing the bug or idea, and our agents
> usually turn it around fast.
The approach is at least better than accepting slop PRs that could have backdoors injected into them.
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.
Or human is completely removed from the development whatsoever..
You could fork and reference it in the issue if you still wanted to contribute.
Then they would be better off contributing to a project that welcomes them.
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.
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.
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.
Of course, one could conclude that another agents screwed up before, still was a good experience.
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.
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
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?
The double-edged sword of choice!
[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.
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.)
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.
But this syntax – egads man! It literally hurts my brain trying to parse it:
fn view(s: &State, _: &mut Cx<State>) -> El {
let t = tok::theme(true);
let label = text(if s.on { "Lights on" } else { "Lights off" })
.font(type_::TITLE).color(t.text);
let knob = el().key("knob").size(18.0, 18.0).radius(9.0).fill(t.knob)
.absolute(if s.on { 18.0 } else { 2.0 }, 2.0);
let switch = el().key("switch").role("switch").label("Lights").checked(s.on)
.focusable(true).size(38.0, 22.0).radius(11.0)
.fill(if s.on { tok::accent(0, true) } else { t.control_off })
.motion(motion::SNAPPY)
.on_press(|s: &mut State| s.on = !s.on)
.child(knob);
col().w_full().h_full().center().gap(16.0).fill(t.bg).child(label).child(switch)
}
e.g. https://github.com/anomalyco/rune/tree/dev/crates/rune-kit/t...
And no live examples...
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...
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.