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).
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)
ecshafer 4 hours 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:
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.
lll-o-lll 3 hours 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.
WD-42 3 hours 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 2 hours 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.
hombre_fatal 2 hours 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.
bschoepke 3 hours ago [-]
Latest way to do native Windows GUI in Rust is pretty cool:
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.
TheRoque 32 minutes 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)
cwillu 2 hours 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.
from tkinter import \*
root = Tk()
a = Label(root, text ="Hello World")
a.pack()
root.mainloop()
KolmogorovComp 2 hours 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.
noelwelsh 6 hours 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!)
WD-42 5 hours 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.
But still, the project solves a legit pain point. And the author seems pretty hands-on with steering the technical implementation details.
Erenay09 3 hours 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 3 hours 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.
AbuAssar 24 minutes ago [-]
Could have named it Zooey
jbritton 2 hours 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 6 hours 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
GPUI is written in Rust, so in this specific case the decision is already somewhat made for you.
torginus 5 hours 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 5 hours ago [-]
> how do I choose between Gooey and GPUI?
GPUI is for rust, not zig
mgrandl 5 hours 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 5 hours ago [-]
Call it Ziggy
cookiengineer 4 hours ago [-]
Sadface :-(
(Author of Gooey [1], a GUI framework for WebASM in Go)
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)
#include <graphics.h> #include <conio.h>
int main() { int gd = DETECT, gm;
}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.
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.
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.
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.
https://www.reddit.com/r/rust/comments/1tql7uf/microsofts_wi...
https://en.wikipedia.org/wiki/Qt_(software)
(Don't tell me here. Make your docs better, so everyone benefits!)
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.
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.
> 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
GPUI is for rust, not zig
(Author of Gooey [1], a GUI framework for WebASM in Go)
[1] https://github.com/cookiengineer/gooey
[1]: https://github.com/creativescala/gooey
https://github.com/chriskiehl/Gooey
And in early 2000, I was in a mailing list for designing a successor/replacement to X11, code-named "Gooey" that never went anywhere.
https://github.com/david-vanderson/dvui
That said, it fills a legit hole in the ecosystem and the author seems to be hands-on with the technical direction.
What's so special about Zig dev that puts them aside from the giants they stand on?