NHacker Next
  • new
  • past
  • show
  • ask
  • show
  • jobs
  • submit
Gooey: A GPU-accelerated UI framework for Zig (github.com)
henry_bone 22 days ago [-]
It'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 of the implementation.

There are still a few new things around that are carefully and thoughtfully developed and put out into the world. zig itself. MitchellH's ghostty. And there's still all the older foundations of really wonderful, robust, software created by people like Linus Torvalds and couple of generations of open source devs, that applied great skill, ingenuity and hard work to produce the very best software.

But I fear that I'm in for a period of lamentation as we get wave after wave of promising sounding developments, but where the reality is low quality, LLM generated crap that you really shouldn't use if you want secure, stable performant, production-ready software.

Seems like perhaps we've been through a golden age of really great software and that now it's coming to a close.

(edited to fix spelling)

Aurornis 22 days ago [-]
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 couple days. You can try to have it do spec documents, code reviews, and cleanup passes but with today's tools these projects reach a point where it's just a swirling mess of pieces duct taped together in a way that passes tests. In my experiments, you quickly reach a point where the usable context depth (which is less than the 1M limits) keeps overflowing before you can get usable refactors in, and you're just going in circles. I know it's theoretically possible to avoid these problems, but in practice you get spaghetti projects like this.

elcritch 22 days ago [-]
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.

willtemperley 21 days ago [-]
> Haven’t hit that wall with GPT-5.5

I’m seeing a similar improvement with Opus 4.8, which is acting like an engineer that cares about correctness. The harder the problem the better it seems to do.

I think a golden age of software is just starting for indie software. It’s just going to take a while to see the first really good results.

SkiFire13 21 days ago [-]
This is what people say after every new model is released though.
reactordev 21 days ago [-]
You have to drink the koolaid if you want to keep tokenmaxxing
elcritch 21 days ago [-]
Who cares about tokens?

I'm wanting to build pieces of software that I've been wanting and often working on for years. These new models are making it possible for me to scale my work to build it.

hiccuphippo 21 days ago [-]
Funny you mention ghostty since they use a lot of AI, but they review and make sure they understand every line.

There should be some way to measure (and display) how much of a project is understood by the humans behind it.

henry_bone 21 days ago [-]
Yeah, I'm aware. MitchellH posts about it quite a bit, most recently about AI "psychosis". Also, much of ghostty was created without the use of AI, I think. More recently, they've been using it to find bugs, improve performance, and generally refine and enhance ghostty and libghostty.

The LLM is the finishing tool, not the architect or core developer.

danielvaughn 22 days ago [-]
To be fair, "excited by the promise only to be disappointed by the reality of the implementation" describes ~95% of my experiences with all software over the last 20 years. In fact only a few exceptions really come to mind - git, treesitter, ffmpeg, and sqlite.
henry_bone 22 days ago [-]
Yeah, maybe it's rose coloured glasses on my behalf. Those examples you mentioned, I would 100% agree with. It's some of the best software out there. And yeah, there's probably always been rubbish about.

I guess I hope that the good stuff keeps coming and the dross falls away. More signal, less noise.

danielvaughn 22 days ago [-]
I do agree with you though. It feels like the industry has steadily been getting worse, AI is just like pouring kerosine on the fire. I'm almost embarrassed to call myself a software engineer now.

On a small bright note, I've gotten AI to help me produce some of my best work over the last couple of months. It may enable sloppy behavior, but it doesn't require it. I have hope that serious work will win out in the end, and that sheer human effort is still the differentiator.

henry_bone 22 days ago [-]
Yeah, there was a good article on here the other day where the author suggested going slower with AI and using it to help produce higher quality output. I think the idea is to be quite "hands on", coding much in the old way, but to use AI to help with, for example, test coverage, error mode detection and handling, refinement of the solution/feature, etc.

At least that's how I read it. :-) I'm learning that there's a place for the LLM but it's the sandpaper, not the chisel.

Pxtl 22 days ago [-]
Hah, that describes my relationship with git itself, actually.
danielvaughn 21 days ago [-]
lol I'm more speaking to reliability than the quality of the interface. git and ffmpeg are not exactly known for the most intuitive API surface, but I don't think I've ever encountered a bug with them in my 17 years. That's a pretty extraordinary thing when you think about it.
Pxtl 21 days ago [-]
Fair point. My problem with git is actually mostly the flaw in the object model itself, more than the dismal API. The fundamental mismatch between "to get a clean history you have to edit/destroy history with squashes and rebases and whatnot" and "editing history destroys the ability to do comparisons of two branches, which basically ruins half of git's functionality from top to bottom when you encounter that problem".

Like even the basic question of "hey did I already merge this branch?" becoming unknowable if you autosquash-on-merge is just nasty.

I've got a million ideas on what the "correct" fix for that problem might be, but imho it's a flaw deep in the heart of git that creates a massive amount of pain.

But I'll give it credit for being rock solid and blazing fast, as you say.

zamalek 21 days ago [-]
That plan smells AI generated:

> Gooey is in better shape than most ~140 KLOC Zig codebases — every directory has a mod.zig, namespaces are layered, and core/interface_verify.zig provides compile-time platform-backend checks. But the architecture has drifted in a few

I too have used AI to plan cleaning up its own mess, and this self-congratulatory prose is extremely consistent ("every directory has a mod.zig", whoop dee woo!).

In my experience, AI is largely incapable of fixing its own mess to an actually competent degree (and full disclosure: I still ask it to, not pointing fingers here) and it's probably due to it walking on egg shells around its own feelings. I've had to tell it to completely change course during cleanup at least 30 times this week.

Also: https://xcancel.com/mitchellh/status/2060088112257372610

mpeg 22 days ago [-]
I find it quite dishonest as github stars used to be (and maybe still are?) the measure of an open source project popularity, and these big, flashy LLM generated repos seem to always get a bit of attention

Have seen it from jobseekers trying to boost their profile with fake projects, founders trying to make their product more attractive to VCs, consultants trying to advertise their services...

I don't always have time for OSS, but every PR I've ever sent has always been hand written, and tested, and has taken into consideration the project coding style and architecture choices – I don't like this new world where developers can't even be bothered to write the docs.

mwcampbell 22 days ago [-]
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?
lelandbatey 22 days ago [-]
You should read the link they provided which goes into detail on the architectural shortfalls of Gooey due to an accelerated development.
dimator 22 days ago [-]
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.
zipy124 22 days ago [-]
it is.
22 days ago [-]
21 days ago [-]
Ajakks 21 days ago [-]
You don't think people have anything to do with the poor implementation? The Golden Age of software already happened? Uh huh, right. This comment reminds me of how people used to speak of Geocities and the early Internet.
ecshafer 22 days ago [-]
This 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 <graphics.h> #include <conio.h>

int main() { int gd = DETECT, gm;

    initgraph(&gd, &gm, "C:\\TURBOC3\\BGI");

    circle(320, 240, 100);

    getch();
    closegraph();

    return 0;
}

Making some shapes and forms wasn't that much work either.

If I think back to VB and Windows (whatever it was then) making a basic window, form and some buttons was so simple and easy, they even made GUI builders because they were so good.

Somewhere along the lines GUIs became overly complex to implement.

WD-42 22 days ago [-]
OK, but what about actually using a GUI toolkit to make an actual application?

You can optimize a library to make it comparatively simple to draw a circle on a screen. But that tells me nothing about binding state, signals, styling, widget hierarchy, etc. Maybe these frameworks look complicated to you because doing something more than drawing a circle is actually more complicated.

cwillu 22 days ago [-]
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.
monster_truck 22 days ago [-]
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 because it's always ready before it's needed. The last "big" update was a guide to running it in parallels on new macs.

chii 22 days ago [-]
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.
hombre_fatal 22 days ago [-]
Agreed. I want a coherent, deliberate architecture for building an application and managing state.

That's the hard part. I'll take on incidental boilerplate (e.g. Elm) if the architecture helps me build and understand applications. Whatever gets me to that latter part.

lll-o-lll 22 days ago [-]
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 remains simple for simple things, sounds like a much more difficult task. I haven’t worked on UI in 20 years, so maybe such tools do exist.

chii 22 days ago [-]
> 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.

SkiFire13 21 days ago [-]
I remember Android Studio's WYSIWYG ConstraintLayout UI builder being pretty good for responsive layouts.
bschoepke 22 days ago [-]
Latest way to do native Windows GUI in Rust is pretty cool:

https://www.reddit.com/r/rust/comments/1tql7uf/microsofts_wi...

coffeeaddict1 22 days ago [-]
This is what you can with Qt:

    #include <QApplication>
    #include <QWidget>
    #include <QPainter>

    class widget : public QWidget {
    void paintEvent(QPaintEvent*) override {
        QPainter(this).drawEllipse(QPoint(320, 240), 100, 100);
    }
    };

    int main(int argc, char *argv[]) {
        QApplication app(argc, argv);
        widget w;
        w.resize(640, 480);
        w.show();
        return app.exec();
    }

It doesn't seem too complicated to me.
ecshafer 22 days ago [-]
That doesn't seem too bad, I agree. Maybe that's why QT is used. I haven't really used QT, but the more modern Windows apis, vulkan, etc all are pretty complicated.
cwillu 22 days ago [-]
FWIW, vulkan is not a GUI library; if you're reaching for it without a clear understanding of why you're doing so, yeah, it'll seem like a very complicated way of doing things.
TheRoque 22 days ago [-]
Vulkan is a graphics API, not a UI library or framework. It's way lower level and if your goal is to make a user interface, you're not really supposed to do it with Vulkan (but you could i guess)
nnevatie 22 days ago [-]
Yeah, it doesn't look too bad on the surface. However, Qt is bad and I'd advice moving away from it if you can. This is based on ~20 years of experience using it in various projects.

The licensing is trying to paint a picture of LGPL being somehow uncertain/evil, the way Qt advocates non-idiomatic C++ practices - I could go on for days, but shall digress.

jetbalsa 22 days ago [-]
Thats why I've always like pytk

    from tkinter import \*

    root = Tk()
    a = Label(root, text ="Hello World")
    a.pack()

    root.mainloop()
nandomrumber 22 days ago [-]
It’s Qt and pronounced ‘cute’.

https://en.wikipedia.org/wiki/Qt_(software)

monster_truck 22 days ago [-]
100% Agreed. My first language was LibertyBASIC. It had everything a kid could want to make a paint program that had (at the time) more features than MSPaint, or whatever little game. Menu bars, undo/redo, dialogue windows, panes, sprites, sound, etc.

Compared to the effort:quality of something like tkinter, LibertyBASIC put it to shame! Not to throw shade, tkinter is perfectly fine but I don't think I would have cared for it at that age.

It also taught me how to pirate software, when I found out the borland compiler required to make .exe's I could give my friends was $200 :)

zionsati 19 days ago [-]
Ahhh a fellow Borland Turbo C++ Dev (we weren't called Devs back then!)

I agree. GUI these days are largely driven by how HTML works and we now have a whole generation of UI Devs (frontend devs) who've never known any other way.

I missed the good old ways of GUI.

danielvaughn 22 days ago [-]
I know I must be underthinking this, but I really don't know why native toolkits can't just implement some codegen thing that takes XML and produces the above.

Like, all of that should be expressable with just

  <graph>
    <circle />
  </graph>
molybd3num 22 days ago [-]
You might like raylib :) https://www.raylib.com/
Gerharddc 22 days ago [-]
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
1matin 22 days ago [-]
Zig still lacks a proper GUI framework that you can actually rely on.
mgerb 21 days ago [-]
ImGui is reliable and Zig makes it trivial to use.
Gerharddc 22 days ago [-]
Fair enough. I was referring to the GUI framework space in general, not specifically for Zig
Simran-B 21 days ago [-]
In what general direction would the innovation be?

I'm not sure if it's actually needed - a lot of things have been tried and the paradigms that persisted you can choose between but it seems to be a matter of taste. I often feel that the real issue is the lack of maturity and stability. I rather want a complete UI toolkit including learning resources (not reference docs!), no matter how boring, instead of super clever implementation that is never in a usable state.

sppfly 22 days ago [-]
Maybe 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.
noelwelsh 22 days ago [-]
Interesting project, but needs documentation. In particular, what's the model it uses? I.e. how are events, state, etc. handled? Normally I'd just work it out from the code examples, but the example in the README is over 200 lines which is too long for me.

(Don't tell me here. Make your docs better, so everyone benefits!)

cookiengineer 22 days ago [-]
Sadface :-(

(Author of Gooey [1], a GUI framework for WebASM in Go)

[1] https://github.com/cookiengineer/gooey

noelwelsh 22 days ago [-]
I also have one [1]. It's a good name :-)

[1]: https://github.com/creativescala/gooey

persedes 22 days ago [-]
not the maintainer, but at first I thought it was python :D

https://github.com/chriskiehl/Gooey

anitil 22 days ago [-]
I've always loved this project, I've used it a lot for making my scripts into internal tools for everyone in the team, even non-technical staff
cookiengineer 22 days ago [-]
We need to make a gooey family of UI frameworks!
Findecanor 22 days ago [-]
I have also found a UI framework in C++ with OpenGL named Gooey (2008-ish).

And in early 2000, I was in a mailing list for designing a successor/replacement to X11, code-named "Gooey" that never went anywhere.

minraws 22 days ago [-]
ooof I did have the nagging feeling I had seen a gui thing with that name before.
WD-42 22 days ago [-]
This is great, we need more of this. It's high time we began to escape the dark ages of rule-by-Electron. See Bitwarden's recent fumble of a redesign.
WD-42 22 days ago [-]
I take it back. This project is pure slop https://github.com/duanebester/gooey/blob/main/docs/architec...
porphyra 22 days ago [-]
Well, the big CLAUDE.md there is a giveaway that it was AI generated:

https://github.com/duanebester/gooey/blob/main/CLAUDE.md

But still, the project solves a legit pain point. And the author seems pretty hands-on with steering the technical implementation details.

KolmogorovComp 22 days ago [-]
I was really eager to use those new frameworks until a recent HN comment raising how power-hungry and wasetul these were for most of their usage (terminal, forms, tui), and now I think it will probably be seen as ‘bloat’ in the future.
1matin 22 days ago [-]
Using 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.
Erenay09 22 days ago [-]
It is great to see the Zig ecosystem growing, even though it was achieved by AI. I wish humans had done it, but I do not wanna start a debate between those who arent fans of AI and those who are.
john_alan 22 days ago [-]
yep, dripping in AI.

It's a real problem, so many projects are adding features at breakneck speed, but with so many bugs and so little understanding.

Maybe that's just how it all works now, but I don't like it.

kristoff_it 22 days ago [-]
Another Zig GUI project that people might be interested in is DVUI:

https://github.com/david-vanderson/dvui

atmikemikeb 22 days ago [-]
DVUI is I think the most mature zig gui project, and a very good immediate-mode approach imo. Here's a recently released open source project built on DVUI in zig: https://fizzyed.it/
jbritton 22 days ago [-]
I wasn’t clear from the description if text rendering is GPU accelerated, or in my case drawing quads from an atlas of characters in a texture is probably more efficient.
vova_hn2 22 days ago [-]
> Inspiration

> GPUI - Zed's GPU UI framework

Cool, but a comparison would also be very helpful.

If I decide to make a GUI app with Zig, how do I choose between Gooey and GPUI?

So far, all I know that GPUI is more mature and has at least one successful project built with it, so...

Also:

> Gooey: Turn (almost) any Python 3 Console Program into a GUI application with one line

> https://github.com/chriskiehl/Gooey

shorsher 22 days ago [-]
GPUI is written in Rust, so in this specific case the decision is already somewhat made for you.
torginus 22 days ago [-]
If I remember correctly, Zed's framework didn't set the goal of being able to draw arbitrary graphics/UI and by constraining that, it basically managed to represent everything with quads and distance fields in shaders, which reduced draw calls and GPU state management to a minimum.
ssernikk 22 days ago [-]
> how do I choose between Gooey and GPUI?

GPUI is for rust, not zig

mgrandl 22 days ago [-]
I mean GPUI is rust and Gooey is Zig so if you wanna do a project in Zig you probably wouldn’t choose GPUI.
LouisvilleGeek 22 days ago [-]
Call it Ziggy
Sakamitsu 22 days ago [-]
"Rewrite GPUI in Zig and make no mistakes" ahh moment. I will never trust software that is written by people who don't understand anything and just generate slop. You have a powerful tool that can help you understand how things work and improve your skills. You can explore huge codebases and find exactly what you're looking for without wasting hours digging through code. Instead, you choose to generate ai slop.
nnevatie 22 days ago [-]
More visual examples are sorely needed - I could only find a small (toy) example of a dialog, that didn't seem to showcase many of the framework capabilities.
snarfy 21 days ago [-]
This is great.

Show me the GUI! We are gonna need more than a couple pics of chat-zig.

AbuAssar 22 days ago [-]
Could have named it Zooey
spartanatreyu 22 days ago [-]
Since it was spat out by an LLM, why not: Sloppy?
22 days ago [-]
amelius 22 days ago [-]
Nice work but honestly I haven't seen convincing arguments for writing medium to large GUI applications in a language that has no automatic GC.
20 days ago [-]
localhoster 21 days ago [-]
Yavos - yet another vibe coded shit
mawadev 22 days ago [-]
I have to say it: Zig devs are on another level
porphyra 22 days ago [-]
It was made with AI though: https://github.com/duanebester/gooey/blob/main/CLAUDE.md

That said, it fills a legit hole in the ecosystem and the author seems to be hands-on with the technical direction.

randypewick 22 days ago [-]
Why? This was AI-made and inspired to Zed editor GUI toolkit, egui, so it's mostly a derived work.

What's so special about Zig dev that puts them aside from the giants they stand on?

22 days ago [-]
Validark 22 days ago [-]
What giants do "we" stand on?
randypewick 18 days ago [-]
My question was genuine: what makes the Zig devs apart from the others, according to the question op?

Arguably, there are important things that Zig devs are doing which are not "Zig dev made" (hence the "giants" I mentioned). NASA 10 rules are now rebranded as "tiger style" and marketed along Zig; Data Oriented Design existed before Zig; LLVM existed before Zig; the authors of gpui, the library that seems to have inspired gooey, apparently did a pretty great job (please correct me if I'm wrong, I don't do graphics, don't use gpui, this is what I understood when gpui came out).

I'm sure Zig devs made pretty great things, too! Does Zig make them apart? Do Zig attracts more capable devs than other languages, maybe? Genuine question!

Validark 17 days ago [-]
I take issue with the statement that "tiger style" is marketed along with Zig. Tiger Style is neither convention nor standard, it's not on ziglang.org, it's not referenced by the Zig Core Team as the end all be all. At present I don't recall them ever referencing it, but I'm sure they have talked about it somewhere.

On the subject of Data-oriented design, it's mostly just the default way of thinking about software in most contexts. The DoD movement is not so much building on predecessors as it is ignoring predecessors who tell us to use OOP and "clean code" for everything.

LLVM is the part of Zig that breaks the most, it's the slowest part of the compiler by leaps and bounds, and takes the most time of the core team to fix the constant breakages it introduces. I'm glad it exists obviously, to some extent, but I wouldn't praise it for much more than its widespread appeal and ease of "adding another pass" compared to GCC and having more of a company-friendly license. It could have been designed a lot better and could be managed very differently and we'd see better results.

GPUI - I bet it's great. I guess I just tend to dislike phrasing like "stand on the shoulders of giants" because I tend to think the best thing hasn't been built yet. "Real engineering has never been tried!" I agree though that an AI port of a Rust library to Zig is probably not what any of us consider the holy grail of engineering.

In short, I think Zig and TigerBeetle and the Handmade Ethos exist not primarily because others paved the way, but because others went astray. Andrew Kelley used to argue with people online about how cross-compilation should be easy for systems languages and got hit by the excuse parade every time. Eventually he decided to quit his day job and solve it himself. Is that standing on the shoulders of giants? I don't think so. Yes, he has technically picked up where others left off, but he's picking up on abject failures and fixing them.

Now there is good engineering within LLVM and Clang, and good developers have done good work on it. I'm not saying everyone who worked on it is stupid or did bad work. However, there are glaring issues at a macro level and organizational level that individual contributors can't fix.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact
Rendered at 21:46:52 GMT+0000 (Coordinated Universal Time) with Vercel.