Go-Gui, Cross Platform GUI for Go.
402 views
Skip to first unread message
Mike Ward
Jun 2, 2026, 8:09:45 PM (11 days ago)
Jun 2
to golang-nuts
I created an X-platform GUI that does not rely on browser technology. It's not a toy but a serious attempt at creating a first-class UI framework. https://go-gui.com
Jorge Javier Araya Navarro
Jun 2, 2026, 8:14:15 PM (11 days ago)
Jun 2
to Mike Ward, golang-nuts
Cool, added to my bookmarks!
--
Sent from GNU Emacs 30.2
Sent from GNU Emacs 30.2
Stephen Illingworth
Jun 3, 2026, 4:30:56 AM (11 days ago)
Jun 3
to golang-nuts
Interesting. What role did Claude play during development?
Nick
Jun 3, 2026, 6:55:14 AM (11 days ago)
Jun 3
to golan...@googlegroups.com
at all which are mature and work well, Fyne & Gio, which also don't
need SDL. Why did you create this, rather than improve one of those?
With all the LLM written code about now, I find "here's an enormous
amount of code that vaguely works with no plan for the future" to
not be very interesting. Maybe that's an unfair characterisation,
but the webpage just reads as written by LLM - the old "if it wasn't
worth your time to write it, it's not worth my time to read it"
chestnut.
alex-coder
Jun 3, 2026, 7:39:15 AM (11 days ago)
Jun 3
to golang-nuts
Mike,
good job !
среда, 3 июня 2026 г. в 13:55:14 UTC+3, Nick:
Randall O'Reilly
Jun 3, 2026, 9:16:58 AM (11 days ago)
Jun 3
to golang-nuts
A few comments on the GUI space for Go (as a co-author of one: https://cogentcore.org
):
* It is maybe not so hard these days to write a GUI framework that kinda works, but there are some really important design choices that make a huge difference in actually using it, especially when you want to do something different than what is already supported.
* The most important issue (IMO) is how you support dynamic updating of widget structure. We spent a long time on that. This new go-gui does not appear to support anything of that nature, at least according an admittedly very superficial look at the example code: just a bunch of declarative structure initializations. Here's an extended discussion of this issue: https://github.com/cogentcore/core/discussions/961
* As this updating issue shows, there are a lot of basic tradeoffs in the GUI design space, that align to some extent with immediate-mode vs. retained-mode. So probably there won't be a one-size-fits-all solution in the world of GUIs.
* However, there is a very long tail in all the details in this space (cross-platform, edge cases, advanced features, internationalization, accessibility, etc), so logically it really doesn't make sense in terms of resource allocation to have a broad proliferation of half-baked frameworks -- it would be much better to have a small number of really solid, mature frameworks.
* Furthermore, when an end-user commits to using a GUI for their app, that represents a HUGE investment in the future viability of the framework. Nobody wants to invest their time coding in something that will soon become abandonware.
* Therefore, from a "rational" perspective, it really would benefit the Go community the most to somehow have an organized, collaborative investment in a few major frameworks, that then develop a sufficiently strong user-base and community to make it worth it for someone to actually use the framework in their own apps.
* In an apparently unrealistically ideal world, Google would actually invest in supporting such an effort, to develop something with serious institutional and official support. I guess that ship has sailed, and it is called Flutter, written in DART, not Go.
* At this point, it seems that Fyne clearly takes the lead in breadth of user-base and support, while Gio may have gone the furthest toward tackling the long tail of issues, at least cross-platform. Furthermore, these two reasonably represent the retained-mode vs. immediate mode approach. So, far, so good.
* However, the reason I didn't just follow the above logic and just use Fyne (I prefer the retained-mode design -- I'm way too lazy to deal with all the code you have to write for Gio and immediate-mode frameworks), is that I found it to be sufficiently problematic in a number design choices, and at the time, lacking in a number features. I think many people find it to be "fine" for most uses, but it is just unfortunate that this most popular and well-supported framework (for which the developers absolutely deserve a huge amount of credit and congratulations!) is perhaps not quite as elegant and powerful as the language in which it is written.
* Anyway, I'm afraid CogentCore is now limping along in a quasi-abandonware state because its main developer went off to college and reasonably has other priorities, and I do not have sufficient bandwidth to do anything other than make it work for my needs. So I'm just as guilty as anyone else of "polluting" the space with half-baked projects! (although, CogentCore is already highly functional, but definitely has its fair share of long-tail issues...)
* So, in conclusion, there is perhaps a clear sense of what would be ideal, and we all love Go so much that we would love to have some really great options for GUI frameworks, but given the real-world constraints on time, effort, motivation, money, history, etc, it is unlikely that anything more ideal will happen. That said, I'd certainly be willing to contribute whatever lessons I've learned in developing CogentCore, if anyone wanted to organize some more collaborative effort going forward.
- Randy
> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com .
> To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/aiAH5MrLhLCZCpWt%40toolbx .
* It is maybe not so hard these days to write a GUI framework that kinda works, but there are some really important design choices that make a huge difference in actually using it, especially when you want to do something different than what is already supported.
* The most important issue (IMO) is how you support dynamic updating of widget structure. We spent a long time on that. This new go-gui does not appear to support anything of that nature, at least according an admittedly very superficial look at the example code: just a bunch of declarative structure initializations. Here's an extended discussion of this issue: https://github.com/cogentcore/core/discussions/961
* As this updating issue shows, there are a lot of basic tradeoffs in the GUI design space, that align to some extent with immediate-mode vs. retained-mode. So probably there won't be a one-size-fits-all solution in the world of GUIs.
* However, there is a very long tail in all the details in this space (cross-platform, edge cases, advanced features, internationalization, accessibility, etc), so logically it really doesn't make sense in terms of resource allocation to have a broad proliferation of half-baked frameworks -- it would be much better to have a small number of really solid, mature frameworks.
* Furthermore, when an end-user commits to using a GUI for their app, that represents a HUGE investment in the future viability of the framework. Nobody wants to invest their time coding in something that will soon become abandonware.
* Therefore, from a "rational" perspective, it really would benefit the Go community the most to somehow have an organized, collaborative investment in a few major frameworks, that then develop a sufficiently strong user-base and community to make it worth it for someone to actually use the framework in their own apps.
* In an apparently unrealistically ideal world, Google would actually invest in supporting such an effort, to develop something with serious institutional and official support. I guess that ship has sailed, and it is called Flutter, written in DART, not Go.
* At this point, it seems that Fyne clearly takes the lead in breadth of user-base and support, while Gio may have gone the furthest toward tackling the long tail of issues, at least cross-platform. Furthermore, these two reasonably represent the retained-mode vs. immediate mode approach. So, far, so good.
* However, the reason I didn't just follow the above logic and just use Fyne (I prefer the retained-mode design -- I'm way too lazy to deal with all the code you have to write for Gio and immediate-mode frameworks), is that I found it to be sufficiently problematic in a number design choices, and at the time, lacking in a number features. I think many people find it to be "fine" for most uses, but it is just unfortunate that this most popular and well-supported framework (for which the developers absolutely deserve a huge amount of credit and congratulations!) is perhaps not quite as elegant and powerful as the language in which it is written.
* Anyway, I'm afraid CogentCore is now limping along in a quasi-abandonware state because its main developer went off to college and reasonably has other priorities, and I do not have sufficient bandwidth to do anything other than make it work for my needs. So I'm just as guilty as anyone else of "polluting" the space with half-baked projects! (although, CogentCore is already highly functional, but definitely has its fair share of long-tail issues...)
* So, in conclusion, there is perhaps a clear sense of what would be ideal, and we all love Go so much that we would love to have some really great options for GUI frameworks, but given the real-world constraints on time, effort, motivation, money, history, etc, it is unlikely that anything more ideal will happen. That said, I'd certainly be willing to contribute whatever lessons I've learned in developing CogentCore, if anyone wanted to organize some more collaborative effort going forward.
- Randy
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com .
> To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/aiAH5MrLhLCZCpWt%40toolbx .
Jason E. Aten
Jun 4, 2026, 12:57:49 PM (10 days ago)
Jun 4
to golang-nuts
Very interesting. I see you have audio support, which Go's garbage collection pauses might glitch (the raison d'etre for Zig lang even existing); have you figured out a way to keep audio playback smooth in Go?
Stephen Illingworth
Jun 4, 2026, 1:04:18 PM (10 days ago)
Jun 4
to golang-nuts
The Zig language was created because Andrew Kelley was writing a real-time
audio application. If you don't have real-time requirements a buffer will do the job just fine.
Robert Engels
Jun 4, 2026, 1:29:47 PM (10 days ago)
Jun 4
to Stephen Illingworth, golang-nuts
I would find it very surprising if Go’s GC pauses affect audio - they are very small, and almost all audio hardware is buffered, and the OS level support is buffered as well.
Java has done audio just fine for decades with far larger pauses for most of its lifetime.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com .
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/04820b4d-86a1-4c4d-8c1f-c18b9af8a9ffn%40googlegroups.com .
atd...@gmail.com
Jun 4, 2026, 5:01:04 PM (9 days ago)
Jun 4
to golang-nuts
Yes, I am in the middle of exploring audio as well and a priori Go is fine there. http://github.com/atdiar/go_RT_audio_benchmark
The point is that it assumes (quite obviously to be fair), enough memory control to ensure 0 allocations during playback.
Which was having me rethink an addendum to the memory region discussion so that we could perhaps introduce something like runtime.NoAlloc(func(){}) that would conservatively ensure no allocs on a specific segment.
Typically used in a request/response situation. That would be conservative only, because we are not sure an append wont allocate for instance. Could use a pragma instead //go:noalloc or whatever (but hey: https://dave.cheney.net/2018/01/08/gos-hidden-pragmas ) ..
Could be a go/vet instead (probably since we are conservative as we can't really be exact).
The static analysis would use ssa with a small abstract interpretation, something a bit similar to bounds checking.
But for soft real time at least, Go should be just fine. And I am not sure that Zig can do much better wrt allocation detection because this is interprocedural. So not quite sure what he meant by that. Seems to me that the issue is the same across languages, GC or not?
Regarding the topic of this discussion, it is funny because I have been working on a UI framework for the past 5 years. But I will keep it as a surprise, I am pretty excited about it and there is overlap in scope (we have audio support as well, we address all platform natively except Desktop for which we rely on wails). It is different enough though. I wont say too much here this is not about what we have done.
But if people think there are enough frameworks and these are sufficient, it is probably because they haven't quite delve into the subject enough to push the envelope beyond the state of the art. Personally I have been nerd sniped around 2020 because I just couldn't get into js frontend development. The abstractions were just not hitting my brain right. i know we are all tired... boss, but I promise, just one more framework... one more... ;D
Cheers,
The point is that it assumes (quite obviously to be fair), enough memory control to ensure 0 allocations during playback.
Which was having me rethink an addendum to the memory region discussion so that we could perhaps introduce something like runtime.NoAlloc(func(){}) that would conservatively ensure no allocs on a specific segment.
Typically used in a request/response situation. That would be conservative only, because we are not sure an append wont allocate for instance. Could use a pragma instead //go:noalloc or whatever (but hey: https://dave.cheney.net/2018/01/08/gos-hidden-pragmas ) ..
Could be a go/vet instead (probably since we are conservative as we can't really be exact).
The static analysis would use ssa with a small abstract interpretation, something a bit similar to bounds checking.
But for soft real time at least, Go should be just fine. And I am not sure that Zig can do much better wrt allocation detection because this is interprocedural. So not quite sure what he meant by that. Seems to me that the issue is the same across languages, GC or not?
Regarding the topic of this discussion, it is funny because I have been working on a UI framework for the past 5 years. But I will keep it as a surprise, I am pretty excited about it and there is overlap in scope (we have audio support as well, we address all platform natively except Desktop for which we rely on wails). It is different enough though. I wont say too much here this is not about what we have done.
But if people think there are enough frameworks and these are sufficient, it is probably because they haven't quite delve into the subject enough to push the envelope beyond the state of the art. Personally I have been nerd sniped around 2020 because I just couldn't get into js frontend development. The abstractions were just not hitting my brain right. i know we are all tired... boss, but I promise, just one more framework... one more... ;D
Cheers,
Amnon
Jun 5, 2026, 5:47:53 AM (9 days ago)
Jun 5
to golang-nuts
Looks interesting.
GUI libraries have traditionally been a bit rubbish in Go.
I used to use fyne, but dealing with CGO and platform dependencies was a massive pain,
and I ended up ripping it out and building my own simplistic rendering library.
For my next gui project I will probably look at https://github.com/gogpu/ui
GUI libraries have traditionally been a bit rubbish in Go.
I used to use fyne, but dealing with CGO and platform dependencies was a massive pain,
and I ended up ripping it out and building my own simplistic rendering library.
For my next gui project I will probably look at https://github.com/gogpu/ui
Reply all
Reply to author
Forward
Search
Clear search
Close search
Google apps
Main menu
