Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gooey: A GPU-accelerated UI framework for Zig

github.com

Post reply on HN
Print view View original

41–50 of 93 posts

Re: Gooey: A GPU-accelerated UI framework for Zig

#41

Post by TheRoque »

ecshafer wrote: post #18
coffeeaddict1 wrote: post #15

Earlier quoted context omitted.

This is what you can with Qt: #include #include #include 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.

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.

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)

Re: Gooey: A GPU-accelerated UI framework for Zig

#42

Post by henry_bone »

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)

Re: Gooey: A GPU-accelerated UI framework for Zig

#44

Post by atmikemikeb »

kristoff_it wrote: post #13

Another Zig GUI project that people might be interested in is DVUI: https://github.com/david-vanderson/dvui

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/

Re: Gooey: A GPU-accelerated UI framework for Zig

#45

Post by monster_truck »

ecshafer wrote: post #12

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 #include int main() { int gd = DETECT, gm; initgraph(&gd, &gm, "C:\\TURBOC3\\BGI"); circle(320, 240, 100); getch(); closegraph(); re…

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 :)

Re: Gooey: A GPU-accelerated UI framework for Zig

#46

Post by monster_truck »

cwillu wrote: post #30
WD-42 wrote: post #20

Earlier quoted context omitted.

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.

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

Re: Gooey: A GPU-accelerated UI framework for Zig

#48

Post by danielvaughn »

henry_bone wrote: post #42

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…

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.

Re: Gooey: A GPU-accelerated UI framework for Zig

#49

Post by Aurornis »

henry_bone wrote: post #42

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…

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.

Re: Gooey: A GPU-accelerated UI framework for Zig

#50

Post by henry_bone »

danielvaughn wrote: post #48
henry_bone wrote: post #42

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…

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.

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.

Post reply on HN