Dear Future architect of some neat new technology to be someday posted on HN please do the following:
If you make anything with a UI, even a GUI stack, always include screenshots. If you make a programming language or programming framework / library, always include code samples!
Really show us nerds the bits we want to see right away, screenshots / code or even a video (fully optional, unless its some type of terminal shell or something where a video would illuminate things!) would sell it better. Many of us are working and don't yet have time to pull down everything to run it locally.
Honestly, even if its not open source, if you're selling a product, SHOW THE PRODUCT not just descriptions of the product.
So, given that this is almost brought up every single time a GUI framework/library is posted on HN, and has been for decades at this point, and given that it apparently doesn't make any difference, what's a better approach for educating the ecosystem at large about this problem? Do we need a website? Nation outreach program? Do we need a arewescreenshottingyet.com landing page with stats to keep track? How can we finally fix this constantly persisting problem of people not adding screenshots for visual things they've built?!
Two options: continue to spend the effort to teach new cohorts community expectations; or eliminate the production of new cohorts so the existing lessons eventually saturate the population.
i mean the whole thing is prob vibe coded. this was actually an exact thing i tinkered with when i first got a claude account. thought hey what if something easy like streamlit ergonomics for golang. gave up on that pretty quickly, it was one of those early "im gonna do something so big because im king of the world now" journeys that helped me learn where the limits of AI really is. with that said id love to see more gui developments in go. im actually not against AI helping speed this up, i just want people to be forthcoming about it. I need to know that they know what they're providing and what they're talking about.
but yeah i went thru the repo and the site and saw like one screenshot of like one component. i really dont think a guy who really actually cared about delivering something like this would kneecap its own success with a lack of screenshots for a GUI solution. that's beyond funny.
as for fyne.io, actually awesome to work with. but holy god it's so ugly, and they've worked themselves into a corner with how they wrote it. theres pr's and discussion ideas to give some users control over something like padding but it'll be a very painful bandaid to pull off and redo. hardcoded vals everywhere.
ive been kind of sitting back and waiting to see if AI was going to help someone who has more inspiration/drive/smarts than me launch something into the spotlight for go gui, but so far the biggest go gui successes still land in the web-technologies stack (wails). i look over at rust and see something like dioxus and i get sad. as far as desktop gui world goes, theres a glaring hole: i actually think aggrid (web tables) is my personal like bare minimum of what im expecting out of a table component. i havent really seen anything that matches it on the native app component front.
Looking forward to a Golang declarative framework.
My advice to the author: invest in rich multi-window support early on. It's easy not to, but you always need it in the end, and it's painful to retrofit.
I feel like there's a great cross-platform UI story to be told with Go, since cross compiling is so easy.
Intro code snippet has two buttons ("+" and "-") in an HStack. Expected them to be arranged horizontally but in the accompanying screenshot they're stacked vertically. Is that intentional?
gova: build failed: exit status 1
# counter
./main.go:20:16: cannot use Counter{} (value of struct type Counter) as gova.View value in return statement: Counter does not implement gova.View (missing method viewNode)
Not encouraging. You can't add 'viewNode' since it's not exported...
I guess they changed the API and didn't update the code or picture.
I once built a small utility using the "Fyne" framework; it was reasonably functional and made it very convenient to compile cross-platform executables (including for Android).
I took a look at your recommendation, "gova"; it seems to be just getting started—keep up the good work!
The repo doesn't say it, but the Author noted on the Gophers Slack #showandtell that the style was inspired by SwiftUI. That VStack example shows it quite well.
The code looks nice, but when I read GUI, I want to see screenshots of GUIs.
Apparently a major dependency is "Fyne", which does show some screenshots on their page:
https://fyne.io/
Came here to say the same. Please add a few screenshots!
Dear Future architect of some neat new technology to be someday posted on HN please do the following:
If you make anything with a UI, even a GUI stack, always include screenshots. If you make a programming language or programming framework / library, always include code samples!
Really show us nerds the bits we want to see right away, screenshots / code or even a video (fully optional, unless its some type of terminal shell or something where a video would illuminate things!) would sell it better. Many of us are working and don't yet have time to pull down everything to run it locally.
Honestly, even if its not open source, if you're selling a product, SHOW THE PRODUCT not just descriptions of the product.
So, given that this is almost brought up every single time a GUI framework/library is posted on HN, and has been for decades at this point, and given that it apparently doesn't make any difference, what's a better approach for educating the ecosystem at large about this problem? Do we need a website? Nation outreach program? Do we need a arewescreenshottingyet.com landing page with stats to keep track? How can we finally fix this constantly persisting problem of people not adding screenshots for visual things they've built?!
Two options: continue to spend the effort to teach new cohorts community expectations; or eliminate the production of new cohorts so the existing lessons eventually saturate the population.
The second approach may have side effects.
i mean the whole thing is prob vibe coded. this was actually an exact thing i tinkered with when i first got a claude account. thought hey what if something easy like streamlit ergonomics for golang. gave up on that pretty quickly, it was one of those early "im gonna do something so big because im king of the world now" journeys that helped me learn where the limits of AI really is. with that said id love to see more gui developments in go. im actually not against AI helping speed this up, i just want people to be forthcoming about it. I need to know that they know what they're providing and what they're talking about.
but yeah i went thru the repo and the site and saw like one screenshot of like one component. i really dont think a guy who really actually cared about delivering something like this would kneecap its own success with a lack of screenshots for a GUI solution. that's beyond funny.
as for fyne.io, actually awesome to work with. but holy god it's so ugly, and they've worked themselves into a corner with how they wrote it. theres pr's and discussion ideas to give some users control over something like padding but it'll be a very painful bandaid to pull off and redo. hardcoded vals everywhere.
ive been kind of sitting back and waiting to see if AI was going to help someone who has more inspiration/drive/smarts than me launch something into the spotlight for go gui, but so far the biggest go gui successes still land in the web-technologies stack (wails). i look over at rust and see something like dioxus and i get sad. as far as desktop gui world goes, theres a glaring hole: i actually think aggrid (web tables) is my personal like bare minimum of what im expecting out of a table component. i havent really seen anything that matches it on the native app component front.
I'll be watching this project.
Looking forward to a Golang declarative framework.
My advice to the author: invest in rich multi-window support early on. It's easy not to, but you always need it in the end, and it's painful to retrofit.
I feel like there's a great cross-platform UI story to be told with Go, since cross compiling is so easy.
Intro code snippet has two buttons ("+" and "-") in an HStack. Expected them to be arranged horizontally but in the accompanying screenshot they're stacked vertically. Is that intentional?
Not encouraging. You can't add 'viewNode' since it's not exported...
I guess they changed the API and didn't update the code or picture.
Fixed it
For those wanting to do it for web pages, I've been keeping an eye on https://www.gomponents.com
Somewhat related (but not declarative): Qt bindings for Go, MIT-licensed.
https://github.com/mappu/miqt
With the compiler flags I tried, binary size was close to that of Gova:
https://github.com/mappu/miqt/issues/147#issuecomment-280033...
Qt bindings for Zig, using the same approach as MIQT:
https://github.com/rcalixte/libqt6zig
How reasonable is it to ask for this to support the WASM target? This would be invaluable for small go projects that can't maintain multiple UIs.
Probably nice, but only 7 commits and over 2 days? Are you in this for the long run?
Yes, here for long run
Very excited every time I see cross-platform GUI in go.
I think the right mental model is that Gova is to Fyne like DaisyUI is to TailwindCSS??
I once built a small utility using the "Fyne" framework; it was reasonably functional and made it very convenient to compile cross-platform executables (including for Android).
I took a look at your recommendation, "gova"; it seems to be just getting started—keep up the good work!
This wraps Fyne? As a long time user of Fyne, what does this provide beyond Fyne itself?
I think styling and ready-made components out of the box?
A "mithril" like syntax. Like you could do (wrapped over multiple lines of course)
m.div([m.h1("title"), m.p(["click", m.a({href:"..."}, "me")])])
you can do (taken from the page)
g.VStack(g.Text(...), g.HStack(...).Spacing(g.SpaceMD))
some people will like this style, others not.
The repo doesn't say it, but the Author noted on the Gophers Slack #showandtell that the style was inspired by SwiftUI. That VStack example shows it quite well.
That's a beautifully designed library, bravo! Will have to give it a go
Thanks, please share your feedback once you’ve tried it.
Nice work. The hot-reload dev cli looks very cool in a compiled-binary world.
Looks quite nice, alternatives to Tauri always welcome although that Tauri is truly fantastic, so much to emulate.
Tauri is basically Electron though. This is a native toolkit, which is another thing entirely.