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.
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.
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.
The tools have gotten fancier, for sure, though.
For larger codebases, things might be different.
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).
It's not my project but I will definitely give the library a try.
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.
bool narrow = cui_viewport_size(ui).x < 760;
cui_row(ui, .width = CUI_FILL, .height = CUI_FILL, .align = CUI_ALIGN_STRETCH) {
if (!narrow) { sidebar(ui, s); cui_separator(ui); }
content(ui, s, narrow); /* a menu button opens the drawer when narrow */
}
cui_sheet(ui, "Menu", &s->drawer, .side = CUI_SIDE_LEFT, .size = 280) { nav(ui, s); }
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."[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.
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.