Rendered at 23:30:06 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
nepthar 3 hours ago [-]
Okay, so this is cool, but also vibecoded by someone who just does frontend. I totally support AI development, but the first commit was 4 days ago and it's entirely written by claude. The UI looks like "the style that that AI comes up with" turned into a C framework.
I don't want to discourage this kind of experimentation, but I also question how much of the last 20+ years of UI and C knowledge was not used in the construction of this project. Also, do I want to build a kanban board in C? Unsure.
Just take care when evaluating this for actual usage.
arecsu 2 hours ago [-]
The thing with these kind of projects is that... What value do they really bring to the table? Because if it's so easy to come up with something like this (and arguably easier over time), then if I need a UI toolkit and components for my app, I can just prompt them right away to obtain something like this with minimal effort. Plus, adapted to my needs, my code, my platforms and language. UI/UX done right is still a dance between design and engineering. But I'm not sure these libraries do solve anything meaningful today that is worth the abstraction and dependency.
pan69 47 minutes ago [-]
I am pretty sure that, even though this project is generated by AI, there will be a large majority of quicks and edge cases and bugs, just like as if a bunch of people would have written it. It's just that the initial bulk of the code was produced in a fraction of the time. All those bugs, quicks and edge-case still need to be resolved (if you were to actually use this). If you prompt your own version of this you just end up with your own set of bugs, quirks and edge-cases. The nature of software hasn't changed, just the speed with which we produce it.
mjburgess 51 minutes ago [-]
~200 USD in 1mo of claude, and 4 days of developer time -- call it 5000 USD
lelandfe 21 minutes ago [-]
I'm not speaking to OP here at all, but I will say that GitHub is riddled with the corpses of weekend vibe coded packages.
It often arrives and gets a week or three of attention, and then it is off to the next thing.
creata 2 hours ago [-]
How does a five-day old C project have 611 stars? Hard to imagine that many people are writing user interfaces in C...
dalemhurley 3 hours ago [-]
It looks like ShadCN-UI which AI likes to use.
mgdev 3 hours ago [-]
Some projects are worth it just for the rebrand.
jitl 14 minutes ago [-]
I’ve also spent the last couple of weeks vibe coding a component-based UI framework for C. My target is embedded hardware with 2 * 300mhz ARM 32 CPU, and a Nintendo 3DS like OpenGL ES 1.1 GPU from DMP: Fujifilm cameras from 2013-2016 like the X70, X-E2, X-T1, X100T. It’s a bit faster than iPhone 2007 on CPU side, and slower on the GPU side due to needing to copy from GPU back to main memory for scan-out. It’s funny how these things seem to come up and then everyone’s doing it.
I didn’t see the code here because I couldn’t find an easy link to its Github. My UI framework i’m calling FocalUI. We do layout and basic geometry with a fork Clay where we added “layer” and “focusable” markers to Clay elements. Instead of drawing immediate mode, we store a list of draw commands and layer geometry in a CoreAnimation-like tree. The renderer composits the layer tree and renders to OpenGL, and we use damage tracking to copy just the changed pixels from the GPU back to the camera’s framebuffer for scan-out.
It’s been a huge effort to add touch inertial scrolling, spring animation, navigation effects etc at 55hz to this device that before only did d-pad nav at 25 Hz, but things are starting to shape up for a release this week :)
hollowturtle 14 minutes ago [-]
I click around on mobile nothing happens, vibe coded trash. I’d spend 10 minutes comparing it to Clay but it’s not worth it I already know the result. The problem with this kind of projects is they expire very soon, the least the effort the least the value
zerr 3 hours ago [-]
More like custom UI components. Native would have been if you had wrapped e.g. Cocoa NSButton on macOS and Microsoft.UI.Xaml.Controls.Button on WinUI.
stephc_int13 3 hours ago [-]
Native is one of those words that means different things depending on context and your background. For me, native means actual binary code running on the machine, not through a JVM or V8 or anything of the sort.
In the Apple world, Native usually means using the system UI components and the Apple guidelines.
i2talics 2 hours ago [-]
> native means actual binary code running on the machine
Wouldn't "native ... for C" be redundant?
stephc_int13 2 hours ago [-]
Not the best title. It is not "for C", but in C. And currently useable on desktop + web but after looking at the project I think it will quickly be ported on mobile etc.
krackers 2 hours ago [-]
There are some libraries that use native widgets on each platform, e.g. libui-ng. Although the issue with things like this is that you aren't going to be able to use all of AppKit, and you get forced into the lowest common denominator expressable by all platforms.
A good middle ground might be having platform-specific pieces but expressed using a more standard domain-specific language. E.g. technically you can already wire up GUIs without interface builder but it's quite verbose. There should be some simpler way to express layout constraints and have button callbacks.
turtlebits 2 hours ago [-]
We need a HN min-release-age flag for posted projects.
Or some flag to ignore users that post these types of projects often.
zamadatix 1 hours ago [-]
The site and community should be structured such that what it values discussion for naturally bubbles up, not different opinionated flags for each interest, fad, or pet peeve.
Though, funnily enough, this kind of info and more is extremely easy to add to HN via a vibed extension. At this point, mine just stops HN from loading completely and constructs its own page (with a proper dark theme and the information I care about).
wavemode 16 minutes ago [-]
Any community needs not only a bubbling up of good content, but also an immune system against bad content. Otherwise in practice you become inundated with spam and noise.
The reason for this is an effort asymmetry: casting upvotes is easy, and most people do it without much thought, whereas determining that something is spam or misinformation requires looking a lot more closely.
hilti 2 hours ago [-]
I usually don't post a lot, but to be honest: the components demo definitely caught my attention (I know it's coded by Claude)
It's not my project but I will definitely give the library a try.
piker 3 hours ago [-]
C increasingly makes sense for compile times if you can have a separate Fable pass on memory safety, etc.
nateb2022 3 hours ago [-]
Assembly is increasingly making sense for compile times if you can have a separate Fable pass on code correctness, etc.
piker 3 hours ago [-]
I think you’re kidding, but wouldn’t you have to maintain different code bases for each platform? C compiler gets you everywhere and WASM.
raphlinus 3 hours ago [-]
Yes, and? As the cost of code generation approaches zero, this starts to make more sense, especially if you do have mechanisms in place to ensure safety and correctness.
I did an experiment a couple weeks ago of having Opus 5.5 translate an MP3 decoder from Rust into Cortex-M33 assembly language, both raw asm and symbolasm. The code was 3x smaller and ~1.5x faster than Rust -O3. These seem like gains that are worth it.
zamadatix 1 hours ago [-]
As the cost of code gen approaches 0 the cost of the test suite actually grows. Not just in definition, but execution.
An MP3 decoder for a single target doesn't really run into that complexity, a UI components library for (Linux, Windows, macOS) * (x86-64, ARM64) suddenly has a 6x multiplier on what was already something with waaay deeper dependencies and integrations than MP3.
At least that's what I've noticed vibing my DE without external libraries. It went really fast when the complexity was small because most of the work was in adding code. Then it started taking longer to build and test, even with optimized builds and tests, than it took for the AI to do its part.
piker 3 hours ago [-]
Yes that makes sense, but if you're iterating on software then I think C will generally win due to its ability to compile cross-platform until you want to build a "release" which you could do by having Fable translate it to ASM at that point.
genxy 3 hours ago [-]
Did you have it go directly to asm or emit the assembly from the Rust toolchain and then contract that? For small stuff, I have been having it write directly, or larger pieces I am having better results via contractions.
raphlinus 2 hours ago [-]
For this experiment I had it write directly.
I should add, part of the experiment was to test whether having variable names and (C style) types would help the LLM. For a task of this size (about 1.5 kLoC Rust, 3k insn asm) it was inconclusive, but for larger projects I suspect it would make a difference.
And the plan for symbolasm is to move past C style types into Rust style and maybe dependent typing, specifically to facilitate automated proofs.
mlfreeman 2 hours ago [-]
at that point, how hard would it be to get the LLM to just make the binary? (iow, llm as compiler)
genxy 3 hours ago [-]
Once you have Wasm, it gets you everywhere and the best path to Wasm is Rust.
drnick1 47 minutes ago [-]
But Rust is unreadable compared to reasonably well written C. It matters if you care to read any of the code yourself and/or want to retain the ability to make manual changes. There is a reason C hasn't been displaced after all this time.
28 minutes ago [-]
arbll 3 hours ago [-]
Funny in a thread that started with `increasingly makes sense for compile times`
genxy 2 hours ago [-]
Fine, I'll make a fast rust compiler.
Rust with no deps and a single compilation unit is already fast.
linkdd 3 hours ago [-]
Just ask the slop machine to translate the binary to every platform.
MomsAVoxell 2 hours ago [-]
C has always made sense for building software as long as you do a memory safety pass.
The tools have gotten fancier, for sure, though.
comex 2 hours ago [-]
I'm observing the opposite phenomenon. I recently vibecoded (with supervision) a 25k-line Rust codebase that takes 15 seconds for every build. If I were writing that by hand, a 15-second build time would drive me crazy and I would stop working until I could find a good way to speed it up. With vibecoding it barely matters, because the interval between builds is much longer and the agent (Opus 5.5) spends most of its time thinking or running tests. Unlike me, the agent rarely makes the kind of trivial mistakes that require rebuilding multiple times in a row.
Leaving memory safety up to a model is wild. That's not a sound guarantee of safety for anything.
apitman 2 hours ago [-]
Since most of my code for work is AI-generated now, I recently started a small side project in part to continue practicing coding by hand, and decided to use C. There's something nice about using a language that's simple enough that I could write/maintain my own compiler if I really had to.
I'm really curious how secure C software would be if reviewed by AI and run exclusively in a WASM runtime.
brabel 2 hours ago [-]
This is amazing, finally a good looking UI framework for a low level language! I will be looking at this next time I need a little UI, since it's nice when you can make an app that has a UI and it's distributed in much, much less than 1MB rather than 300MB as most Electron apps.
slopnt 16 minutes ago [-]
Design is essentially a clone of egui in C.
dbvn 2 hours ago [-]
This is a major spillage of CUI
wg0 3 hours ago [-]
Looks like ShadCN. That too in C. It's really really elegant.
EDIT: It's immediate mode.
saidnooneever 4 hours ago [-]
this looks really sweet actually. didnt dig into the backing code yet but the examples look really nice and clean to implement a UI with. well done.
kettlez 2 hours ago [-]
Clearly vibecoded, but it looks really nice. The widget id generation seems pretty naive, I wonder how well it handles dynamic UIs.
skydhash 3 hours ago [-]
This looks like built by someone raised exclusively on web and touch technologies, forgetting that both are the results of constraints. The web was not meant to be a UI platforms and have poor primitives, and touch devices lack precise positioning and a physical keyboard.
People do need to differentiate between UX primitives and something that just looks different.
hollowturtle 13 minutes ago [-]
Also ids are generated with discrete values? Never seen something like that cui_make_id(ui, label) ^ 0xC0EC0001u
mllev15 3 minutes ago [-]
One of the most hideously ugly C codebases I’ve ever laid my eyes on. I don’t even care if it’s bug free. What value does this add to the programming community? A “library” generated by a morally bankrupt megacorporation’s plagiarism machine. Good job learning nothing, contributing nothing except another shadcn looking UI shitkit, and further training the beast that will eat you alive one day. I will now use this opportunity to promote Clay (not mine obviously), which is absolutely loaded with heart and soul, and is a beautiful piece of engineering: https://www.nicbarker.com/clay
rafael-lua 1 hours ago [-]
Can't wait for RUI, the vibecoded Rust version of this vibecoded C project.
all2 3 hours ago [-]
The acronym collision is entertaining. I now want to use CUI to mark up my CUI.
CrzyLngPwd 3 hours ago [-]
Looks lovely, but without long term support and hostory, I wouldn't touch it with someone else's long stick.
pearcoder 2 hours ago [-]
Since AI has removed the bottleneck of writing code, so I understand why not go directly C. This could bite back sooner or later.
keel-control 1 hours ago [-]
as elon musk said eventually the only language used would be assembly for systems programming because programming languages are only needed by humans.
bigyabai 55 minutes ago [-]
That's a very easy thing to say when you own an AI company, and much harder to agree with when you pay by the token.
MomsAVoxell 2 hours ago [-]
You know what this needs now? A Lua REPL.
hard_times 16 minutes ago [-]
Holy! Yes!
dvt 2 hours ago [-]
So funny seeing these kinds of frameworks being vibe-coded. I can tell the author has never used the zillions of frameworks the LLM was trained on. Writing (and maintaining) this kind of code is absolute nightmare fuel.
There's a reason QT uses XML for their layouting, there's a reason people prefer Tauri + Vue/React, there's a reason Swift uses declarative paradigms in all their UI code. It's not that you can't build good UI frameworks in low-level languages; for example, I think Go's Fyne[1] is a pleasure to use. But people actually used their brains when designing that framework, as opposed to "hey Claude build a UI framework in C, make no mistakes."
That looks pretty readable to me. Somewhat noisier than SwiftUI due to all the repeated "cui_", but not much. I've seen far worse.
I would be more concerned about the opposite problem: the fact that it's apparently reactive and thus inherits the same performance pitfalls as every other reactive UI framework. Retained-mode UI is much uglier (at least if you build the UI in code) but doesn't have these issues.
edit: actually it's worse than reactive, it's full immediate-mode render-everything-every-frame.
weego 1 hours ago [-]
There's a reason QT uses XML for their layouting
You're on shaky ground using xml for ui layouts as posterchild for good developer ergonomics.
dvt 41 minutes ago [-]
It’s like democracy: the worst except for all the others.
stephc_int13 2 hours ago [-]
I think you are missing the point entirely.
The use of C, in that case, was likely made for performance reasons and avoiding dependencies.
The author added dozens of complex widgets in a few days, AI driven of course. The intended audience is not manual coders, you would show some examples to the clankers and ask for you UI and custom widgets.
huhtenberg 3 hours ago [-]
Any pre-built examples? Even if it's something like a calculator.
annoyingnoob 3 hours ago [-]
CUI - Controlled Unclassified Information.
MomsAVoxell 2 hours ago [-]
$ tree lab
lab
├── BUI
├── CUI
├── GPUI
└── TUI
dabluecaboose 2 hours ago [-]
Yeah I just did a double take at my desk reading this
blahyawnblah 3 hours ago [-]
Yeah. Not good acronym for this.
zerr 3 hours ago [-]
Can you please prompt your agent to generate a C++ binding?
Luke2642 3 hours ago [-]
Looks great, but node editor is janky on mobile.
ipsum2 2 hours ago [-]
I wonder how this does with embedded devices. Would be cool to get an ESP32 with smooth animations/nice UI.
cincinnatus 3 hours ago [-]
Shame to put effort into encouraging more C code. All C code needs to be torn out by the roots. I don't care how carefully crafted it is and how many Fable passes have been done, it is inherently unsafe.
I don't want to discourage this kind of experimentation, but I also question how much of the last 20+ years of UI and C knowledge was not used in the construction of this project. Also, do I want to build a kanban board in C? Unsure.
Just take care when evaluating this for actual usage.
It often arrives and gets a week or three of attention, and then it is off to the next thing.
I didn’t see the code here because I couldn’t find an easy link to its Github. My UI framework i’m calling FocalUI. We do layout and basic geometry with a fork Clay where we added “layer” and “focusable” markers to Clay elements. Instead of drawing immediate mode, we store a list of draw commands and layer geometry in a CoreAnimation-like tree. The renderer composits the layer tree and renders to OpenGL, and we use damage tracking to copy just the changed pixels from the GPU back to the camera’s framebuffer for scan-out.
It’s been a huge effort to add touch inertial scrolling, spring animation, navigation effects etc at 55hz to this device that before only did d-pad nav at 25 Hz, but things are starting to shape up for a release this week :)
In the Apple world, Native usually means using the system UI components and the Apple guidelines.
Wouldn't "native ... for C" be redundant?
A good middle ground might be having platform-specific pieces but expressed using a more standard domain-specific language. E.g. technically you can already wire up GUIs without interface builder but it's quite verbose. There should be some simpler way to express layout constraints and have button callbacks.
Or some flag to ignore users that post these types of projects often.
Though, funnily enough, this kind of info and more is extremely easy to add to HN via a vibed extension. At this point, mine just stops HN from loading completely and constructs its own page (with a proper dark theme and the information I care about).
The reason for this is an effort asymmetry: casting upvotes is easy, and most people do it without much thought, whereas determining that something is spam or misinformation requires looking a lot more closely.
It's not my project but I will definitely give the library a try.
I did an experiment a couple weeks ago of having Opus 5.5 translate an MP3 decoder from Rust into Cortex-M33 assembly language, both raw asm and symbolasm. The code was 3x smaller and ~1.5x faster than Rust -O3. These seem like gains that are worth it.
An MP3 decoder for a single target doesn't really run into that complexity, a UI components library for (Linux, Windows, macOS) * (x86-64, ARM64) suddenly has a 6x multiplier on what was already something with waaay deeper dependencies and integrations than MP3.
At least that's what I've noticed vibing my DE without external libraries. It went really fast when the complexity was small because most of the work was in adding code. Then it started taking longer to build and test, even with optimized builds and tests, than it took for the AI to do its part.
I should add, part of the experiment was to test whether having variable names and (C style) types would help the LLM. For a task of this size (about 1.5 kLoC Rust, 3k insn asm) it was inconclusive, but for larger projects I suspect it would make a difference.
And the plan for symbolasm is to move past C style types into Rust style and maybe dependent typing, specifically to facilitate automated proofs.
Rust with no deps and a single compilation unit is already fast.
The tools have gotten fancier, for sure, though.
For larger codebases, things might be different.
I'm really curious how secure C software would be if reviewed by AI and run exclusively in a WASM runtime.
EDIT: It's immediate mode.
Take the chips and rating as an example
https://yappologistic.github.io/CUI/#/c/chips-and-rating
It’s purely aesthetic as functionality (and ux) wise, chips are not different from checkbox with labels and rating is just a discrete slider.
And as I thought, you can see the duplicate code for switch and checkbox here.
https://github.com/yappologistic/CUI/blob/f1202e6d98cdc297f9...
People do need to differentiate between UX primitives and something that just looks different.
[1] https://fyne.io/
I would be more concerned about the opposite problem: the fact that it's apparently reactive and thus inherits the same performance pitfalls as every other reactive UI framework. Retained-mode UI is much uglier (at least if you build the UI in code) but doesn't have these issues.
edit: actually it's worse than reactive, it's full immediate-mode render-everything-every-frame.
You're on shaky ground using xml for ui layouts as posterchild for good developer ergonomics.
The use of C, in that case, was likely made for performance reasons and avoiding dependencies.
The author added dozens of complex widgets in a few days, AI driven of course. The intended audience is not manual coders, you would show some examples to the clankers and ask for you UI and custom widgets.
Well, fewer problems!