At first I was very excited about this project. After reading the comments, I'm now deeply saddened by it... Given how much competition there already is in the GUI framework space, it's very difficult to see why something hastily thrown together by AI would get much traction. To really make an impact in this space, I think we'll need to see something thoughtfully designed that really tries to innovate in some profound way rather than just being more of the same
Gooey: A GPU-accelerated UI framework for Zig
61–70 of 93 posts
Re: Gooey: A GPU-accelerated UI framework for Zig
#62Earlier quoted context omitted.
You should read the link they provided which goes into detail on the architectural shortfalls of Gooey due to an accelerated development.
Tbh, the link itself sounds like LLM as well, spotted a few emojis in there. I suppose I could be wrong, but I feel like we're all getting good at sniffing generated language.
it is.
Re: Gooey: A GPU-accelerated UI framework for Zig
#63Re: Gooey: A GPU-accelerated UI framework for Zig
#64It's not particularly revelatory to point out that this project has been generated largely by LLM (claude most likely, given the CLAUDE.md in the repo). Also looks like a bit of introspection has happened ... https://github.com/duanebester/gooey/blob/main/docs/architec... I wonder if this is just what we get now: low quality code, expressed rapidly. We are excited by the promise only to be disappointed by the reality…
We're in the messy transition period where our old indicators of a promising GitHub project are too easily replicated by someone letting Claude Code run for a few days. A year ago it would have taken someone months of nights and weekends effort to get this much code up and running. That person would have developed a good intuition for the architecture and where it should go. Now Codex or Claude can bang it out in a c…
I don’t know, GPT-5.5 has been very effective for me. It’s not perfect but the quality of refactoring it can do is awesome.
Previous models both GPT and Claude would struggle with the larger picture more. Pretty quickly they’d do one off hacks. Eventually they’d code themselves into a wall if you weren’t careful.
Haven’t hit that wall with GPT-5.5 yet. New changes or improvements on a GUI library I’m building seem to be constant in time per feature.
Though I’m talking only 10k’s of LOC. Also I’m using Nim which is both strongly typed and concise.
Re: Gooey: A GPU-accelerated UI framework for Zig
#65Maybe I'm wrong, but I'm really skeptical about projects like this. 200000 lines of code addition in 3 months, basically 2000 lines per day. I don't think any human brain is capable to handle such cognitive complexity, unless the code is all plain data get/setters, which any framework is certainly not. For me a good way to use LLM is to learn how to build something big by writing a tiny one with it. But this only gives a shallow understanding of a big system. For any critical complex system you want to maintain for a long time, LLM is in no way a good choice.
Re: Gooey: A GPU-accelerated UI framework for Zig
#66At first I was very excited about this project. After reading the comments, I'm now deeply saddened by it... Given how much competition there already is in the GUI framework space, it's very difficult to see why something hastily thrown together by AI would get much traction. To really make an impact in this space, I think we'll need to see something thoughtfully designed that really tries to innovate in some profoun…
Zig still lacks a proper GUI framework that you can actually rely on.
Re: Gooey: A GPU-accelerated UI framework for Zig
#67It's not particularly revelatory to point out that this project has been generated largely by LLM (claude most likely, given the CLAUDE.md in the repo). Also looks like a bit of introspection has happened ... https://github.com/duanebester/gooey/blob/main/docs/architec... I wonder if this is just what we get now: low quality code, expressed rapidly. We are excited by the promise only to be disappointed by the reality…
Have you found evidence that the code is actually low-quality, or is that just an assumption based on the fact that it's evidently largely LLM-generated?
[deleted]
Re: Gooey: A GPU-accelerated UI framework for Zig
#68Using an AI-generated GUI framework written in Zig (a lang with no safety guarantees despite being quite helpful to human devs) is a brave decision.
Re: Gooey: A GPU-accelerated UI framework for Zig
#69Earlier quoted context omitted.
VB was used to create a great many data-munging applications in its time, and while they were never pretty, they were lightning fast, largely consistent, and generally far more reliable than what we currently have.
A relative's business has been and is still completely driven by a VB app. It's goddamn ugly but most businesses of their size in that industry have been paid subscribers for 30? years at this point. Most notably its the only piece of software they've never had to ask me for help with at all. The only updates it gets anymore are little data packs when laws/regulations change and it seems like they automated that beca…
And that is the perfect piece of software - it does exactly what is asked, and no more. It has simple enough "architecture" to let anyone maintain it (by adding new stuff that regulations demand, easily), and continues to function without modification otherwise.
Re: Gooey: A GPU-accelerated UI framework for Zig
#70This looks good. But the thing that always lets me down on UI frameworks is how much freaking work it is to get something on the screen. My first language was Borland Turbo C++. It was so comparatively simple to do stuff. If I want to write a circle on the screen its just this: #include #include int main() { int gd = DETECT, gm; initgraph(&gd, &gm, "C:\\TURBOC3\\BGI"); circle(320, 240, 100); getch(); closegraph(); re…
So VB6 or earlier is what you are probably remembering, and VB has a fascinating history as it started life as a wysiwyg design tool before it was attached to any language. However, you need to remember that these simpler tools were a product of a much simpler set of requirements. Fixed themes, fixed screen size, fixed aspect ratios. I imagine a wysiwyg editor that gives you all the power of, say, CSS, and yet remain…
> a wysiwyg editor that gives you all the power of, say, CSS, and yet remains simple for simple things, sounds like a much more difficult task.
so the problem is CSS isnt it?
The constraints and flexibility of CSS makes it difficult to make a simple outcome easy to specify in similarly easy CSS.