Rendered at 21:34:29 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
brabel 37 seconds 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.
nepthar 1 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 8 minutes 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.
dalemhurley 35 minutes ago [-]
It looks like ShadCN-UI which AI likes to use.
mgdev 56 minutes ago [-]
Some projects are worth it just for the rebrand.
zerr 50 minutes 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.
krackers 13 minutes 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.
stephc_int13 36 minutes 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 14 minutes ago [-]
> native means actual binary code running on the machine
Wouldn't "native ... for C" be redundant?
stephc_int13 11 minutes 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.
piker 1 hours ago [-]
C increasingly makes sense for compile times if you can have a separate Fable pass on memory safety, etc.
nateb2022 1 hours ago [-]
Assembly is increasingly making sense for compile times if you can have a separate Fable pass on code correctness, etc.
piker 59 minutes 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.
genxy 46 minutes ago [-]
Once you have Wasm, it gets you everywhere and the best path to Wasm is Rust.
arbll 41 minutes ago [-]
Funny in a thread that started with `increasingly makes sense for compile times`
raphlinus 53 minutes 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.
piker 45 minutes 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 44 minutes 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 31 minutes 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 26 minutes ago [-]
at that point, how hard would it be to get the LLM to just make the binary? (iow, llm as compiler)
linkdd 53 minutes ago [-]
Just ask the slop machine to translate the binary to every platform.
MomsAVoxell 26 minutes 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 25 minutes 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.
For larger codebases, things might be different.
lpghatguy 25 minutes ago [-]
Leaving memory safety up to a model is wild. That's not a sound guarantee of safety for anything.
pearcoder 22 minutes 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.
wg0 1 hours ago [-]
Looks like ShadCN. That too in C. It's really really elegant.
EDIT: It's immediate mode.
kettlez 32 minutes ago [-]
Clearly vibecoded, but it looks really nice. The widget id generation seems pretty naive, I wonder how well it handles dynamic UIs.
saidnooneever 2 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.
huhtenberg 46 minutes ago [-]
Any pre-built examples? Even if it's something like a calculator.
MomsAVoxell 23 minutes ago [-]
You know what this needs now? A Lua REPL.
CrzyLngPwd 57 minutes ago [-]
Looks lovely, but without long term support and hostory, I wouldn't touch it with someone else's long stick.
skydhash 1 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.
Luke2642 46 minutes ago [-]
Looks great, but node editor is janky on mobile.
zerr 57 minutes ago [-]
Can you please prompt your agent to generate a C++ binding?
all2 1 hours ago [-]
The acronym collision is entertaining. I now want to use CUI to mark up my CUI.
dvt 33 minutes 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.
stephc_int13 7 minutes 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.
annoyingnoob 53 minutes ago [-]
CUI - Controlled Unclassified Information.
MomsAVoxell 24 minutes ago [-]
$ tree lab
lab
├── BUI
├── CUI
├── GPUI
└── TUI
dabluecaboose 28 minutes ago [-]
Yeah I just did a double take at my desk reading this
blahyawnblah 43 minutes ago [-]
Yeah. Not good acronym for this.
cincinnatus 1 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.
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.
In the Apple world, Native usually means using the system UI components and the Apple guidelines.
Wouldn't "native ... for C" be redundant?
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.
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.
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.
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!