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.
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.
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.
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.
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.
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.
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.
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:")
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/
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.
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)
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..
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.
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 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
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.
composition with transparencies is the main one
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"
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.
> 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.
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.
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
why are we giving more accessibility to agents than to like disabled human users?
What does "native" mean to these people. Native UI means using the widgets provided by the operating system. This is not that.
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.
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.
So it's a UI framework by agents, for agents?
Another Vibe coded slop which will probably be not maintained after 3-4 weeks.
> 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.
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:")
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/
They ain't running in CI.
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.
Why do you say 0 tests? Are the other statements similarly precise?
...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 doesn’t look immediate mode to me?
It presumably powers OpenCode, the agent harness.
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.