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.
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.
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.
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.
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.
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.
What an odd statement. Unreadable code is unreadable regardless of language. I’ve seen my fair share of unreadable C. Indeed Rust can be ugly in advanced use cases with heavy syntax but C’s simpler syntax does not mean it is always readable either. Hell, I've seen unreadable Python and Lua!
C has in fact been displaced in many places. Just because it survives in a few holdout contexts is a historical artifact more than a testament to the language.
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.
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.
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.
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.
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.
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.
I promise you, this project has not addressed the quirks and edge cases. I don't think many of these components have even been tested by a human, because there are glaring omissions that you'd see if you just played around with them for a minute.
Do you think that this person is going to stick around and fix those issues, or just move on to the next impressive project in a week?
> there are glaring omissions that you'd see if you just played around with them for a minute.
That was more or less the point I was trying to make. You can vibe-code your own variant of this project (as the poster I was replying to suggested) but you run into the same problem that you need many more iterations of refinement. If we think that everyone is simply going to vibe-code their own UI frameworks (or whatever) going forward then I think that is a wrong assumption. The nature of software development hasn't changed, just the speed at which we can produce it.
This is just a comment in general, not specific to the project posted by OP.
It has no value, and you can tell basically immediately.
People are becoming extremely lazy and shipping the first slop the model generates because they get a rush from putting their stuff in tot he world as fast as possible.
However, I would bet significant money that all the projects like this (where every aspect has hallmark slopisms (the vibe interface design, the copy) will lose out to projects that are also heavily AI coded but that took the time and care to actually polish and differentiate themselves and thus are later to the game because they shipped after a few weeks or a month of work and refinement instead of a day.
AI can save you a lot of time but it can't save you from your own lack of restraint and your inability to discern and be an objective judge of the value your thing will have to other people. For software, mere existence is no longer sufficient anymore. Anyone can generate whatever you made instantly if you put zero effort or discernment into it. This is why so many of the Ainfluencers are emphasizing "taste".
But even taste won't save you on the end either, since anyone can clone your stuff as soon as it ships.
I personally think the future of software is probably just two extremes:
1. Personal dinky vibe coded apps that all have their individual creator as the sole user.
2. Large scale apps that don't work without significant marshaling of hard physical resources (e.g. LLMs themselves).
All the middle bits, user applications that target a specific problem space but that run locally and/or don't need legions of data centers and networks to run, will probably just die eventually. Maybe a couple of established apps will stick around in business contexts because employees all using their own personal apps and workflows causes too much coordination overhead, but at the consumer level I fully except everyone will be just vibing their own stuff pretty soon here.
Very little. The motivation of contributing the open source is almost never a product, it is the feedback loop of work and achievement. Nobody will contribute to this kind of thing, because there is no feedback loop here.
People (rightly so) complain about the wastefulness of datacenters and AI mostly due to the pollution, and "projects" like this one not only do not justify that pollution, but worsen it.
We have GPUI, we have web components, we have Clay UI. No one needs another C UI library.
Well, actually they do, but the LLM wouldn't know why. You gotta have used all these to figure it out, and then spend months wondering upon a better design, researching old experiments by random people in archived repos for inspiration. LLMs are useful only for that last part, quickly comprehending a strange repo you found from 15 years ago.
> ... but also vibecoded by someone who just does frontend
This is the kind of thing I can't understand. They're trying to solve a problem they don't have. Assuming other people might need it, without understanding anything about that domain.
There's a thing that people who are infatuated with AI can't understand: anybody else has the same power as you! The old entrepreneurship-like ideal of trying to create something new just for the sake of innovation doesn't work anymore. Innovate on something that solves a problem you have, for you. Otherwise it's just slop, introducing chaos to system, increasing internet entropy.
This is something I'm seeing more often... vibecoded is starting to mean somebody just delegated their thinking to AI and whatever AI spit they just shipped blindly.
I think this is quite different then what I'd call AI-assisted coding, in which the engineer is still in the reins and you can see, even if you see the tales of a lot of code in short time, that the code has actually been looked over and polished by a human.
There might be a place for vibecoded software where only the outcome matter and the code is soft of disposable, but a library or a framework doesn't seem to be the place for that.
Yea, there's some nuance here. If you're a senior engineer in the pre-LLM world, you're likely spending more of your time guiding a team than you are writing lines of code. Perhaps you're writing prose for code review guidelines and guardrails around architectural patterns, with trust that this is followed and propagates to the org. Perhaps you're giving guidelines that anything that implies a business-level decision needs to be escalated and have a rollout plan, not just hardcoded.
The question is: if you're doing this same thing, but with LLMs as your "reports," is it vibe coding? The term was once an epithet, but I think it's expanded to refer to the technique of not living in an IDE, not the objective function.
If your objective function places an emphasis on maintainability: vibe coding can be a positive. If not: it can be a source of great pain. As with many things, it's the wielder, not the technique.
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.
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.
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.
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.
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.
Actually the reason is a very good one: most people design UIs graphically (Qt Designer, XCode Interface Builder, etc.), and UIs naturally lend themselves to the structure found in XML.
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.
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).
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.
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.
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
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 :)
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
this is actually pretty neat, probably can replace lvgl or wayland-based GUIs, it's not mission critical, as long as it works I'm fine with vibe coding.
So, i downloaded it, built and tried some demos. On the positive side:
1. It looks and behaves very polished. From playing around with the gallery the only issues i noticed is that the mouse wheel goes to the "outermost" control instead of the "innermost" and that there isn't a right click / context menu for text input fields with commands like copy, paste, etc (but the common shortcuts do work - including editing shortcuts like home, end, shift+movement, ctrl+d, etc).
2. According to btop the applications seem to use relatively little memory compared to other apps that look similar (~73MB). Of course it "helps" that other apps that look similar tend to use either Electron or some embedded web browser that balloons memory usage to several hundred MBs :-P.
3. There are practically no dependencies - even OpenGL seems to be an optional runtime dependence. Using objdump shows that it only depends on libm, libSM, libX11, libXext and -of course- libc. This is neat for self-contained applications.
4. The files are also relatively small - after stripping debug info from the release binaries (not sure why they're there) the hello world example is ~323KB, most examples (that use richer UIs) are somewhere between 350KB and 400KB and the gallery that contains everything is 1.4MB.
5. The UIs feel very light and snappy/responsive.
On the negative side:
1. The apps always seem to use ~4-5% CPU here - this is because they keep drawing the window all the time. Mangohud shows them not capping the FPS at all - which is good for smooth and responsive input, but drawing should stop if there are no changes to the scene/UI that need updates.
2. The code looks very messy - i do not see any `.clang-format` or anything like that. If you're going to use LLMs for writing the code IMO you should have both automatic code formatting and a `CODE_STYLE.md` (or something like that) for specifying how the code should look. It doesn't avoid the LLMisms in code but helps a lot to keep it readable (IMO at least).
3. There is no custom theme support (you can customize some aspects of its theme but you cannot make it look like, e.g, Windows 95, Mac OS X Leopard or Morrowind).
I used to look at the SW projects posted on HN, but not anymore. Everything is just AI slop now. Filtering the signal from the noise is way too much work for something that was supposed to be fun.
saidnooneever | 20 hours ago
all2 | 19 hours ago
wg0 | 19 hours ago
EDIT: It's immediate mode.
piker | 19 hours ago
nateb2022 | 19 hours ago
piker | 19 hours ago
raphlinus | 19 hours ago
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 | 19 hours ago
genxy | 19 hours ago
raphlinus | 18 hours ago
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 | 18 hours ago
zamadatix | 17 hours ago
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.
linkdd | 19 hours ago
genxy | 19 hours ago
arbll | 19 hours ago
genxy | 18 hours ago
Rust with no deps and a single compilation unit is already fast.
drnick1 | 17 hours ago
lazypenguin | 14 hours ago
C has in fact been displaced in many places. Just because it survives in a few holdout contexts is a historical artifact more than a testament to the language.
MomsAVoxell | 18 hours ago
The tools have gotten fancier, for sure, though.
lpghatguy | 18 hours ago
comex | 18 hours ago
For larger codebases, things might be different.
efficax | 17 hours ago
skydhash | 19 hours ago
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.
hollowturtle | 16 hours ago
cincinnatus | 19 hours ago
Luke2642 | 19 hours ago
Well, fewer problems!
nepthar | 19 hours ago
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.
mgdev | 19 hours ago
dalemhurley | 19 hours ago
arecsu | 18 hours ago
mjburgess | 17 hours ago
pan69 | 17 hours ago
creata | 15 hours ago
Do you think that this person is going to stick around and fix those issues, or just move on to the next impressive project in a week?
pan69 | 13 hours ago
That was more or less the point I was trying to make. You can vibe-code your own variant of this project (as the poster I was replying to suggested) but you run into the same problem that you need many more iterations of refinement. If we think that everyone is simply going to vibe-code their own UI frameworks (or whatever) going forward then I think that is a wrong assumption. The nature of software development hasn't changed, just the speed at which we can produce it.
This is just a comment in general, not specific to the project posted by OP.
voidhorse | 11 hours ago
People are becoming extremely lazy and shipping the first slop the model generates because they get a rush from putting their stuff in tot he world as fast as possible.
However, I would bet significant money that all the projects like this (where every aspect has hallmark slopisms (the vibe interface design, the copy) will lose out to projects that are also heavily AI coded but that took the time and care to actually polish and differentiate themselves and thus are later to the game because they shipped after a few weeks or a month of work and refinement instead of a day.
AI can save you a lot of time but it can't save you from your own lack of restraint and your inability to discern and be an objective judge of the value your thing will have to other people. For software, mere existence is no longer sufficient anymore. Anyone can generate whatever you made instantly if you put zero effort or discernment into it. This is why so many of the Ainfluencers are emphasizing "taste".
But even taste won't save you on the end either, since anyone can clone your stuff as soon as it ships.
I personally think the future of software is probably just two extremes:
1. Personal dinky vibe coded apps that all have their individual creator as the sole user.
2. Large scale apps that don't work without significant marshaling of hard physical resources (e.g. LLMs themselves).
All the middle bits, user applications that target a specific problem space but that run locally and/or don't need legions of data centers and networks to run, will probably just die eventually. Maybe a couple of established apps will stick around in business contexts because employees all using their own personal apps and workflows causes too much coordination overhead, but at the consumer level I fully except everyone will be just vibing their own stuff pretty soon here.
up2isomorphism | 9 hours ago
creata | 18 hours ago
simplesocieties | 15 hours ago
We have GPUI, we have web components, we have Clay UI. No one needs another C UI library.
HexDecOctBin | 12 hours ago
Well, actually they do, but the LLM wouldn't know why. You gotta have used all these to figure it out, and then spend months wondering upon a better design, researching old experiments by random people in archived repos for inspiration. LLMs are useful only for that last part, quickly comprehending a strange repo you found from 15 years ago.
CrociDB | 15 hours ago
This is the kind of thing I can't understand. They're trying to solve a problem they don't have. Assuming other people might need it, without understanding anything about that domain.
There's a thing that people who are infatuated with AI can't understand: anybody else has the same power as you! The old entrepreneurship-like ideal of trying to create something new just for the sake of innovation doesn't work anymore. Innovate on something that solves a problem you have, for you. Otherwise it's just slop, introducing chaos to system, increasing internet entropy.
_benj | 14 hours ago
This is something I'm seeing more often... vibecoded is starting to mean somebody just delegated their thinking to AI and whatever AI spit they just shipped blindly.
I think this is quite different then what I'd call AI-assisted coding, in which the engineer is still in the reins and you can see, even if you see the tales of a lot of code in short time, that the code has actually been looked over and polished by a human.
There might be a place for vibecoded software where only the outcome matter and the code is soft of disposable, but a library or a framework doesn't seem to be the place for that.
btown | 14 hours ago
The question is: if you're doing this same thing, but with LLMs as your "reports," is it vibe coding? The term was once an epithet, but I think it's expanded to refer to the technique of not living in an IDE, not the objective function.
If your objective function places an emphasis on maintainability: vibe coding can be a positive. If not: it can be a source of great pain. As with many things, it's the wielder, not the technique.
monegator | 12 hours ago
CrzyLngPwd | 19 hours ago
zerr | 19 hours ago
annoyingnoob | 19 hours ago
blahyawnblah | 19 hours ago
dabluecaboose | 18 hours ago
MomsAVoxell | 18 hours ago
zerr | 19 hours ago
stephc_int13 | 19 hours ago
In the Apple world, Native usually means using the system UI components and the Apple guidelines.
i2talics | 18 hours ago
Wouldn't "native ... for C" be redundant?
stephc_int13 | 18 hours ago
pjmlp | 7 hours ago
krackers | 18 hours ago
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.
huhtenberg | 19 hours ago
Luke2642 | 19 hours ago
dvt | 18 hours ago
[1] https://fyne.io/
comex | 18 hours ago
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 | 18 hours ago
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.
weego | 17 hours ago
You're on shaky ground using xml for ui layouts as posterchild for good developer ergonomics.
dvt | 17 hours ago
eviks | 12 hours ago
Sure there is, it's just that the reason might be a very bad one unlike what you imply
dvt | 11 hours ago
ogoffart | 3 hours ago
kettlez | 18 hours ago
MomsAVoxell | 18 hours ago
hard_times | 16 hours ago
MomsAVoxell | 35 minutes ago
https://github.com/seclorum/CUI.seclorum/tree/cui-lua-repl
pearcoder | 18 hours ago
keel-control | 17 hours ago
bigyabai | 17 hours ago
brabel | 18 hours ago
turtlebits | 18 hours ago
Or some flag to ignore users that post these types of projects often.
[OP] hilti | 18 hours ago
It's not my project but I will definitely give the library a try.
zamadatix | 17 hours ago
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 hours ago
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.
ivanjermakov | 15 hours ago
ImPostingOnHN | 15 hours ago
O_H_E | 11 hours ago
eitland | 7 hours ago
Yes, I sometimes wish for a downvote button, but so far I have more often wished for a way to silently make flagging a no op for users that abuse it.
ivanjermakov | 6 hours ago
apitman | 18 hours ago
I'm really curious how secure C software would be if reviewed by AI and run exclusively in a WASM runtime.
ipsum2 | 18 hours ago
dbvn | 18 hours ago
rafael-lua | 17 hours ago
slopnt | 16 hours ago
hollowturtle | 16 hours ago
jitl | 16 hours ago
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 | 16 hours ago
jitl | 15 hours ago
mllev15 | 16 hours ago
bschwindHN | 14 hours ago
_sigh_
synergy20 | 13 hours ago
PenguinCoder | 13 hours ago
eviks | 12 hours ago
qphe95 | 11 hours ago
badsectoracula | 11 hours ago
1. It looks and behaves very polished. From playing around with the gallery the only issues i noticed is that the mouse wheel goes to the "outermost" control instead of the "innermost" and that there isn't a right click / context menu for text input fields with commands like copy, paste, etc (but the common shortcuts do work - including editing shortcuts like home, end, shift+movement, ctrl+d, etc).
2. According to btop the applications seem to use relatively little memory compared to other apps that look similar (~73MB). Of course it "helps" that other apps that look similar tend to use either Electron or some embedded web browser that balloons memory usage to several hundred MBs :-P.
3. There are practically no dependencies - even OpenGL seems to be an optional runtime dependence. Using objdump shows that it only depends on libm, libSM, libX11, libXext and -of course- libc. This is neat for self-contained applications.
4. The files are also relatively small - after stripping debug info from the release binaries (not sure why they're there) the hello world example is ~323KB, most examples (that use richer UIs) are somewhere between 350KB and 400KB and the gallery that contains everything is 1.4MB.
5. The UIs feel very light and snappy/responsive.
On the negative side:
1. The apps always seem to use ~4-5% CPU here - this is because they keep drawing the window all the time. Mangohud shows them not capping the FPS at all - which is good for smooth and responsive input, but drawing should stop if there are no changes to the scene/UI that need updates.
2. The code looks very messy - i do not see any `.clang-format` or anything like that. If you're going to use LLMs for writing the code IMO you should have both automatic code formatting and a `CODE_STYLE.md` (or something like that) for specifying how the code should look. It doesn't avoid the LLMisms in code but helps a lot to keep it readable (IMO at least).
3. There is no custom theme support (you can customize some aspects of its theme but you cannot make it look like, e.g, Windows 95, Mac OS X Leopard or Morrowind).
On the "it depends on your taste" side:
1. It is clearly very web and mobile inspired.
2. It uses an immediate mode approach.
zombot | 3 hours ago