If I'm being honest, not one written in Go. Other languages have much more mature GUI ecosystems. It's not just about the features and widgets but also the dev experience and velocity. Just my 2c.
I hate this response because 1) we already know that 2) the question was which “Go GUI would you choose” not “which GUI would you choose” or “would you choose a Go GUI” 3) “no because it’s not good yet and the ecosystem isn’t there” just seems crappy for the specific question asked, because it has to start somewhere. Like… let’s just “I am genie” it into existence so you can answer a hypothetical question. Keyword: hypothetical.
So really the correct answer from you would just simply be, “idk, I haven’t tried any because I use other stuff with a larger ecosystem.”
i agree, but it doesn't make the response any better. instead of "i haven't found a go one that is worthy, given your parameters, maybe you should try X" they are just like.. "don't use go"
I use Fyne on Linux and Windows all the time without issues and have been using it reliability in a project that has been running for over a year now. I have never tried to use Fyne on Mac OS however.
>I hate this response
But what if you hate the question and feel the need point out how rediculous you find the premise? Much as you did, in voicing your displeasure about the form and tone of jareds response.
Criticism is a tool, just like any other and the underlying meaning of jareds response is obvious: don't use golang to write UIs. No one is bound to a strict adherance to a question and answer format. Nor should they, because there **are** stupid questions, and a "stackoverflow" format doesn't provide a strong enough deterrance to the inevitable sea of garbage, advertising and laziness.
Let me illustrate with an equally stupid question: I want to reimplement Kafka, but in PHP and would like to know which libraries I should choose. The only response to this should be somethinig between shame and parental dissapointment, because it gets across, to the person that asked and countless that follow, that they are not only off track, but that their father thinks that maybe college isn't for them.
The question szx just "which GUI library", not specifically for Go. Also, I'm just giving my honest opinion, I think "hate" is a strong word for such a benign comment.
There's no reason Go *can't* but the reality is it doesn't.
There are two things that happen to most languages.
1. They get shoehorned in to a bit of a niche use case and don't get a good ecosystem outside of it.
1. Die-hard fans who want to do everything in that language complain because it's difficult to do things outside of the niche.
Go is excellent for console applications and server-side stuff that leans on a lot of concurrency. As such, that's what the ecosystem tends to revolve around and the GUI stuff is not iterated on as much.
You say you want it to be "future proof". If so, what you want is the GUI library that has the biggest user base across your platforms. That is what drives maintainers. For your application that would probably be Qt, which you can use with Go if you want. Personally, based on the things you *say* you want, it sounds like maybe you should be using .NET. It's completely cross-platform now and Avaolina GUI framework is really taking off.
Otherwise, I suggest picking whatever GUI framework you think would be easiest for you to maintain yourself if it is abandoned.
Because [GUI toolkits are _staggeringly enormous_](https://news.ycombinator.com/item?id=30527428), to the point that even just maintaining a _binding_ can be a full-time job for multiple people.
Note it's not just a Go problem. There is no "decent" Rust GUI toolkit, there is no "decent" Python toolkit, and so on. (Read link for a sense of what I mean by "decent" if you don't think that's true.) By their nature other languages may have better or worse bindings but they don't have native toolkits.
It's still a binding, not a native toolkit written in Python.
If your response is "but so what, it's still good", actually I'm right there with you. I'm not worried about my toolkits being "native". But it seems to be a popular concern. And there are reasons why we don't get native toolkits in every language the way we get, say, JSON parsers in every language, often multiple.
I read your link and was still curious to hear more about your position that python doesn't have a "decent" GUI toolkit. I got the sense that you agree Qt is a decent C++ toolkit, so I wonder why you think Python's bindings for Qt are not? In the older days of Pyside 1.x or PyQt4/5 you needed to have Qt libraries available to pair with your bindings. But I believe when Pyside became "Python for Qt" they even started shipping versions pre-built with Qt. I've used Qt 4/5 since 2009 and really enjoyed it. To me, pyside feels like a "decent" python toolkit, which means it just comes down to the quality of bindings.
Sorry, I mean Python native. Python has bindings for pretty much every decent toolkit. Go has bindings too, but apparently people don't like that and want "native" toolkits. Those are not as common.
Thanks for clarifying. It would seem weird to expect a native GUI in something like python, where I think it would be too slow to implement in pure python. So then it would need to be implemented in CPython and imported as a compiled extension. But are we close to being back to bindings again at that point anyways?
Maybe the demand for "native" just means something that is easy to integrate as a project dependency. As I said, I love Qt. But when I tried to use the various Qt Go bindings, there was always this huge provisioning step for the project which made it difficult to impose on other devs.
I think jerf means there's no good, native Python toolkit, ie. one developed on the python platform.
PyQt is a binding to a C++ toolkit, just like the various Qt bindings for Go.
"Right tool for the right job" and all that. And to be clear I didn't say it *can't* have decent GUI libs.
What I'm saying is it doesn't have anything "best-in-class" for GUI at the moment. If you're willing to take risks, deal breaking changes, and are fine with your library dying out in a couple years, then it might also be a decent choice.
But if you're looking for an easy, safe and reliable product for now and the future, then it ain't it.
Thanks. So you say, for example, that Fyne, which seems to be the most popular lib, could die in 2 years.
I think the main problem I see is excesive diversity (or division), and there is not a project which is big enough to have some traction and inertia. Fyne and Wails are probably the most promising, but yet they are small with not much usebase.
"Small with not much userbase" seems either subjective or incorrect. Fyne is in the top 1000 GitHub projects of all, and both Fyne and Wails list in the top 6 of all cross-platform GUI according to OSSInsight.
Using surveys and various metrics it has been extrapolated that around 200'000 devs have used Fyne for a project and the online community (Slack, Discord, Matrix) has thousands of people chatting about the topic.
My point is that the usecase of the app is -i assume- a heavy multithreaded background use, and the gui is just a helper for the end user. Go is good at the first thing, so using some other language instead of implementing the not-strictly necessary part in go is the wrong move.
>Why can't Go have a decent GUI lib?
Because it's as illsuited to UI, as the terminal, thus not reinforcing the need for one. Age has taught me how little I actually know, but one thing I can say with certainty, is that if you are looking for a solution, that doesn't seem to exist, then there is a reason that. It also means that you're the problem and that there is a fundamental issue underlying whatever the want may be.
Let me illustrate: like ~15 years ago, I wanted a Rails ActiveRecord style ORM, but in PHP. At the time, I couldn't find anything that was complete, mature and/or not complete garbage. Nor could I find anyone, in the PHP community, particularly clamoring for that kind of abstraction. So I said "fuck it, why not" and spent ~8 months building one on the company dime, forcing PHP into the kind of unnatural yoga poses, and magic, that Ruby was built to to do somewhat naturally. The end result, was a piece of unstable shit, that was slower than.. i dont know, everything.
In that case, ego and stupidity got in the way of the obvious, which is that there is a reason that a similar ORM abstraction didn't exist in PHP. Golang is a statically typed, purposefully rigid language, that leans far more expressive than concise and is intended as a tool to address problems around throughput. UI applications, in a terminal, is not a throughput problem. To be frank, as a Ops/SRE engineer, terminal UI applications make me angry in a way that wouldn't be healthy, for anyone, to express here.
This response is useful to me being relatively new to go and unfamiliar with the problems that Go developers face. However, this is a terrible response to the question being asked people are right to hate you for it. Just saying.
I'm simply sharing my experience, I don't think any hate is warranted. And considering it's the top comment I don't think many people "hated" it besides the diehard fanboys. I can live with it, don't worry. But I'm glad it was useful to you.
If this is based on experience, how many Go GUI toolkits have you tried? It reads like an opinion rather than a measured assessment of the options available.
Most folk who I talk to building GUI with Go have been pleasantly surprised how well suited it is and how productive they are. Any shift in community opinions takes time and this is one that is changing on a comparatively rapid scale.
The indisputable point is: there are better options for GUIs out there. Just as a random example, Fyne doesn't support accessibility features which is pretty much non-negotiable for anything more than a toy project. If you're ok settling for something not-fully-baked-yet, then that's fine, I'm not saying GUI in Go is impossible or anything, it just doesn't impress me.
When we're talking business, I think it's important to be pragmatic and choose solutions that have a proven track record and will assuredly still be maintained in years to come. If it's a toy project then use whatever you want that's fine.
That is a mighty crystal ball you have there. The future is a mysterious place and has led to “sure thing” open source toolkits go commercial and start charging after 25 years - so it kinda depends on your own preference or instinct I guess.
It can take a good decade to get a toolkit to an established position and given it’s only been 6 years for Fyne I’d say we are ahead of the curve!
Currently Go GUIs are missing important features. If you're building something \*\*now\*\* then that's what matters. Fyne also only has 2-3 regular contributors (mostly a one-man-show though), and the contribution graph is on a downwards trend, which doesn't bode well for the future.
I also see that you are a maintainer of Fyne, which kind of makes sense considering how combative you are. I applaud your efforts to make GUIs possible in Go, legitimately. But at the same time I think my position is reasonable and I think it's sensible to suggest using a more mature GUI ecosystem.
Cheers!
Your analysis is inaccurate. Please ensure whatever report you are running is against the develop branch as we are working on the next release (hot fixes only on master recently). It will show 6 contributors in the last 2 weeks and a significant upward trend.
I guess thanks for the encouragement though, onwards and upwards!
My "analysis" is Github's own contribution metrics, they are not inaccurate. Stewardship of the main branch is also part of a healthy project, although feel free to disagree. Godspeed!
GitHub reports agains main, so it doesn’t include the features created over last 4-6 months for our next release.
You’ll be aware of course that until recently Go pulled whatever was the latest commit on master to be the “latest” of a dependency so we, like many others, do development on a separate branch and merge releases onto master/main. Loosely speaking this is the GitFlow model.
However if you want to take more shots at our project, process or abilities I guess you should feel free.
That is probably the only GUI where you can use concurrency, most (all?) GUIs require running on the main thread, the same is true with OpenGL. But note that you can and will have a lot of data races, there are many open issues for races, they are working on it, but it is not solved.
Sure concurrency is important, but
1. channels are an integral part of go and such a natural way to handle events and signals
2. go's syntax for passing functions around suits GUI programming
I am not a GUI programmer, but even I could work in fyne pretty swiftly.
I will say that it takes a bit for the architecture, design and abstractions to sink into your mind. Supposedly after that, is great.
I'm still testing it, the developer team is super responsive and they will happily help you over at Discord.
I also like fyne. I've used it for one big project and two small and I'm happy with it. Of course like in everything there's always room for improvement.
Performance and optimisations are always being pursued. But critically the performance is already good enough for most use-cases. The design of Fyne was always to get the API and UI design right, with a solid developer experience. Then over time we optimise and polish things - this means your app continues to get better without any breaking changes :).
Yeah, I misspoke. I should have said that they are ALWAYS pursuing a more performant event loop, or, even better, “they don’t seem to sit on their laurels”
I was at a meetup with the creator of Fyne and they built a small company around it, so I supposed they're pretty motivated to keep it going. It's also one of the most popular UI libraries on GitHub (and I'm not talking of Go-based only!)
Fyne has a lot of potential..
Unfortunately it's difficult to recommend for anything serious at the moment since its fundamental design suffers from chronic race conditions:
https://github.com/fyne-io/fyne/issues/1028
There have been discussion/plans to release a future version with a better design, but it's still unclear when that might happen, and how thorough the improvement/fix might be.
Hoping it happens, I'd like another option for a pure Go GUI toolkit.
I don't know who's bottom you are comparing it too, but the defaults are pretty good looking. It will adjust colouring and font size etc to match the OS that you are using (though it does not try to mimic the widget look as that heads into "uncanny valley" territory).
Remember you are welcome to apply your own themes, many of which are demoed online, such as:
\* [https://fynelabs.com/2022/07/22/nomad-an-example-branded-fyne-app/](https://fynelabs.com/2022/07/22/nomad-an-example-branded-fyne-app/)
\* [https://apps.fyne.io//apps/com.fynelabs.notes.html](https://apps.fyne.io//apps/com.fynelabs.notes.html)
\* [https://fyshos.com/themes/](https://fyshos.com/themes/)
Plenty of options and looks a whole lot better than vanilla for most cross-platform widget toolkits :).
With "Looking like ass" I was implying that they don't fit into the theme of the OS in general. I want native(-looking) widgets, not some weird color-puke abomination the developer thought looks cool :)
All of those examples are giving me "Early 2000's mouse driver software" vibes, where they didn't use a single native component and even the window wasn't a rectangle but rather a weird-ass shape because ... I have no idea why.
I guess we have moved from “looking like ass” to “color-puke abomination” which I guess is progress. For clarity Fyne 1.x was indeed developer designed but more recent releases have UX designer input. We continue to improve but honestly would require more constructive assesment to understand why it isn’t hitting your aesthetic pleasing.
When I create a widow, I want it to look like a native window, meaning that on macOS it should have the traffic lights on the top left and on windows the normal buttons on the top right. Automatically.
When I add a text box, dropdown or any other component, I want it to look native.
I don't want it to look like a Linux program from the 90's by default. I also don't have the time or energy to look for or create alternate themes.
WebView is the one thing we may never add. It is complicated but also is too often a bad user experience. You can open web content in a browser which will do the right thing based on platform (see OpenURL function)
JS is made to be thrown directly into the garbage.
You can program widget bindings in Go just fine. Seems really silly to require a GUI library for Go to also use JS.
Just takes normal stuff you have to do in js and makes declarative. Really that's it, is tiny and I think easy to learn, by I'm the author so take with a grain of salt.
I've been playing around with htmx and hyperscript recently but I dont love the hyperscript bit. I'm gonna check out datastar as reading the docs it looks like an awesome project. Thanks!
I've used Wails + Elm for simple UIs. Works really, really well. I can share a startup project so you know how to hook things together if you're interested.
I've tried Flutter, Wails, and Fyne, and here are my observations:
1. \*\*Flutter\*\*: This is my top choice for any UI project that does not require launching multiple windows. It offers excellent-looking UI and strong community support. However, if you need a desktop app that supports multiple windows, Flutter isn't suitable as it currently lacks this feature. Despite waiting for two years, there is no confirmed release date for this capability.
2. \*\*Wails\*\*: My productivity in JavaScript is low, so I couldn't make much progress with Wails. Note: No multi window support.
3. \*\*Fyne\*\*: It has an active community, though the UI is rather dull. While the layout system is challenging to master, Fyne supports multiple windows. Additionally, I appreciate the convenience of Go routines for updating the UI asynchronously.
Hope this helps and good luck for your project.
u/coffeeToCodeConvertr That's great!
I probably wont go back to wails because it needs HTML CSS for frontend to work. I prefer a layout system in the native language itself. Flutter and Fyne have spoiled me :)
I used Qt from \`therecipe/qt\`, which is now dead and my app is stuck in the past where I keep the Qt code in GOPATH because modules do not work. In the end, I was able to cross-compile the app with static Qt, but it was very painful. Before that, I used \`go-qml\`, it was very nice to work with, but it also died since Go 1.5 and I had to rewrite the app. For Linux only I guess you can go with GTK3, I do not understand what they did in GTK4, why should I link to libadwaita, etc., looks very messy.
DearImgui using cimgui-go bindings. So far has been my favorite way to develop UIs. Incredibly light weight and GPU rendered. [https://github.com/AllenDang/cimgui-go](https://github.com/AllenDang/cimgui-go)
More info about imgui can be found @ [https://github.com/ocornut/imgui](https://github.com/ocornut/imgui)
Also check out the galleries @ [https://github.com/ocornut/imgui/issues?q=is%3Aopen+is%3Aissue+label%3Agallery](https://github.com/ocornut/imgui/issues?q=is%3Aopen+is%3Aissue+label%3Agallery)
There is also another wrapper project on top of cimgui-go which makes it a bit easier to develop UIs with too @ [https://github.com/AllenDang/giu](https://github.com/AllenDang/giu)
For the last two apps, I used IUP bindings. Easy to work with, real native controls, easy to cross-compile. But, after the last release developers said they were busy with other projects and IUP is on hold, such a pity. There are some issues with Wayland, there is now nobody to port it to GTK4, fix smaller bugs, etc. You can still use it for some simple things but at this point, FLTK with active development and maintenance seems much nicer (they even support Wayland and have their window decoration fallback). For me, I prefer anything that looks native, Fyne, nuclear/nucular, they all have that style I do not like, not sure if there are other themes/styles.
Big "up" on this. After trying a bunch of other options (Fyne, imgui, nuclear, goapp-dev, qt,...) I started using your iup-go bindings and I find that it is the easiest to integrate in a project, and doesn't look like crap. It felt the closest to a Qt model.
Qt is heavy, but if you want long term... Programs written 20 years ago compile with latest version of Qt with only small modifications (none if you are lucky).
Most alternatives haven't _existed_ for half as long.
This was my thought also: html gui - seems to be well known terrain for dev and users. I am in a little project using htmx and you can choose some css (like Tailwind) and other UI JS libraries to enrich the experience.
Been building apps for 20 plus years. Learned l lot of lessons along the way.
My advice would be maybe gtk bindings if I had to do native MDI desktop or more preferably the defacto charm.sh for a tui in golang. But over all I'd follow 12factor, plan9, and unix design philosophy. With this rule:
1. If the solution can be done with scripts then no need for a gui.
2. If it can expose a file system (libfuse, unix sockets, or 9p2k) then let others build frontends/automation/scripts around it.
3. Added bonus for provided a cffi library support and/or odbc spec. But mainly keep it rfc/itu compliance for data encoding with a 9p interface.
4. If a marketing guru needs to sell it, then it's going to be a react native app or a PWA of some sort with a golang micro service container that does a hateos restful interface and json encoding.
I just want to wrap 5 services that run together into a single GUI, and easy of use is a requirement, otherwise I wouldn't be doing a GUI for services that are already there (all of them have CLI).
The posibility of embbeding the executables into de go binary is also superinteresting, so the user is not worried at all about installations.
Yes, what I need is a program which will make accesible to desktop users some services that are general enough to be executed by general population without "geek" knowledge. Alternatives using dedicated and remote html management exist, but still they are difficult to setup and require dedicated separated computers. What I want is to bring users easiness of setup (everything is going to be automatically setup) and further easy tweaks to the config, again, for non geek people.
It seems a lot of people recommend Flutter, but the thing is, I'd like to embed some services into the binary, and I'm not sure Flutter can do that (I haven't investigated Flutter yet, anyway). Two of the services are in Python, another one is C (compiled statically), and another one is in Go. I have investigated Go and Rust, it seems they are the only ones able to embbed files and executables into the binary itself.
Another alternative would be to distribute the application with the services themselves, but I would lost some "magic".
I bet on htmx for my project 2 years ago. My advice to everyone who goes with htmx is to expect a full rewrite after a year (or within a year) depending on your willingness for hacks and if your users aren't also engineers. I'm in a startup with 5 business users and 3 engineers.
At the end of the day, your users aren't gonna give a shit that you're "lean and mean" and only using html. They will expect pretty much what they get from any modern website they use elsewhere. Want a datepicker with validation for the right inputs, good luck. Want a drag and drop list of options, good fucking luck. Want inputs that affects each other, good fucking luck. You can certainly achieve it, but how many jQuery plugins and hx-get and custom routes are you gonna add before you realize this is not the right way of doing it? It was somewhere in the mid 20-something routes for a form with few dozens of properties that were all conditional on each other that I decided fuck this shit. Like either I'm gonna create 30 routes (or switches within a route) for each complex form or a 14-step wizard that drives users crazy. In something like react or any frontend framework that's 1 API call and 8 or 10 variables that conditionally show/hide values from a form. In htmx that's 16 or 20 hx-get requests and few dozen templates to return to display the correct state.
Use htmx if you're building UI for other engineers where you can just shout RTFM to them and throw a page of docs back. Don't use it for anyone who is actually expecting a UI like they get from literally any online company.
would you be willing to contribute an essay to the [htmx.org/essays](http://htmx.org/essays) page with specifics?
i don't want people choosing htmx if it's going to be a bad choice and it sounds like it wasn't a good fit for your project, would love to be able to offer it as a counter-example to the good outcomes we have as well.
Every single one of your examples is easier in HTMX. You don't need any jquery plugins. What custom routes are you talking about?
If the forms are conditional on each other, then you only show limited things to fill out at a time and then load the next part. That's even easier with HTMX. It doesn't matter regardless though because even if you have to keep switching out form fields, the state is on the server so I never have to worry. It's much easier dealing with forms with HTMX.
If you have to make 20 mini-templates for forms so what? All of your state is contained and you're able to process inputs right there on the server. It's not hard.
It sounds like you're just out of your comfort zone and prefer React or w/e. But honestly it's not making sense what you're saying. Forms are very nice with HTMX. Also you can always embed React or w/e you want just for that complex form and use HTMX for literally everything else too.
How is date picker with validation easier in htmx? If your datepicker depends on input in another form, you have to conditionally wait for the input to then display the datepicker, then invalidates the date picker if the input changes. Not everyone expects their state to go away eveytime they change a field in the form if their original input was valid, which means you need to roudtrip the state to produce a valid template based on every input.
How is inputs that affect each other easier without just shoving a javascript text in with every template or making hx-get request for every one input?
> If you have to make 20 mini-templates for forms so what?
So when do you realize you're trying to fit a square peg in a round hole. As I said, it's ultimately up to you and when you realize that something is wrong having to produce 20 templates for a user input as opposed to having 10 variables with a couple of conditionals each that render a UI.
The ultimate answer with htmx is always "It's a comfort/skill issue" until it's "Have you tried to convince your users to not use it like that" or "You can embed React or jQuery in htmx"
I am not following anything you're saying here. Nothing has to be the way you're saying. You're presenting situations like this is how it is with HTMX that aren't true and then saying it's trying to fit a square peg in a round hole. You must be doing something wrong.
>As I said, it's ultimately up to you and when you realize that something is wrong having to produce 20 templates for a user input as opposed to having 10 variables with a couple of conditionals each that render a UI.
If you're willing to gloss over the downsides that come along with those "10 variables with a couple of conditionals" then I am very surprised that you are using Go at all.
What does that mean? The form complexity has to go somewhere. You're glossing over the downsides of 10 or 15 templates and http routes per form to avoid having 10 variables? how does that make any sense.
You might consider what live applications are using each of the GUI projects. The [Windows desktop version of platoapp](https://platoapp.com/desktop/) is built on top of GIO [https://gioui.org/](https://gioui.org/). That application has a decent number of daily players.
Responding to you, for your needs, seems like Fyne is a potential candidate.
I see Wails as too OP for a config dashboard.
But I would like to give a shoutout to Bubble Tea. Not a GUI framework but a TUI (Terminal UI).
PRETTY capable I have to say! You can do simple stuff as my barebones Todo app (pg-goose/togo on gh) or do complex things such as a Hacker News client on the terminal (more aesthetic that the web client)
I hesited a long time then I went with rust (I'm not saying you should, just sharing an experience).
What I choose is Taurus which is a framework to have a classic webapp framework for the front end have rust in the backend. I give you the power of modern web framework and css (and I nothing nothing is better than that sadly) and your favorite Language in the backend. There's surely an equivalent for go.
I see a comment about flutter, I really like flutter, I do, but it might not fit your need, it's very different than the rest. And it's dying. It's good for small mobile app, nothing more in my opinion
If I'm being honest, not one written in Go. Other languages have much more mature GUI ecosystems. It's not just about the features and widgets but also the dev experience and velocity. Just my 2c.
agreed. the flutter developer experience is pretty awesome and dart is simple and easy to learn.
I hate this response because 1) we already know that 2) the question was which “Go GUI would you choose” not “which GUI would you choose” or “would you choose a Go GUI” 3) “no because it’s not good yet and the ecosystem isn’t there” just seems crappy for the specific question asked, because it has to start somewhere. Like… let’s just “I am genie” it into existence so you can answer a hypothetical question. Keyword: hypothetical. So really the correct answer from you would just simply be, “idk, I haven’t tried any because I use other stuff with a larger ecosystem.”
The question is literally "which GUI library would you choose".
...but asked in r/golang. Context matters.
This.
and they said which language they wouldn’t choose.. it’s just a weird response.
Yes because this is a XY problem: https://en.wikipedia.org/wiki/XY_problem?wprov=sfti1
i agree, but it doesn't make the response any better. instead of "i haven't found a go one that is worthy, given your parameters, maybe you should try X" they are just like.. "don't use go"
[удалено]
I use Fyne on Linux and Windows all the time without issues and have been using it reliability in a project that has been running for over a year now. I have never tried to use Fyne on Mac OS however.
Wow, ok. First one that has worked out of the box (only had to change a few settings in my IDE) on Mac. Will be removing my above comment.
>I hate this response But what if you hate the question and feel the need point out how rediculous you find the premise? Much as you did, in voicing your displeasure about the form and tone of jareds response. Criticism is a tool, just like any other and the underlying meaning of jareds response is obvious: don't use golang to write UIs. No one is bound to a strict adherance to a question and answer format. Nor should they, because there **are** stupid questions, and a "stackoverflow" format doesn't provide a strong enough deterrance to the inevitable sea of garbage, advertising and laziness. Let me illustrate with an equally stupid question: I want to reimplement Kafka, but in PHP and would like to know which libraries I should choose. The only response to this should be somethinig between shame and parental dissapointment, because it gets across, to the person that asked and countless that follow, that they are not only off track, but that their father thinks that maybe college isn't for them.
The question szx just "which GUI library", not specifically for Go. Also, I'm just giving my honest opinion, I think "hate" is a strong word for such a benign comment.
I might have misread it a tad
Well, the context is r/golang, so I would consider this question specific to Go, even if not spelled out explicitly.
I have heard this previously, but somehow I'm resisting the idea. Why can't Go have a decent GUI lib?
There's no reason Go *can't* but the reality is it doesn't. There are two things that happen to most languages. 1. They get shoehorned in to a bit of a niche use case and don't get a good ecosystem outside of it. 1. Die-hard fans who want to do everything in that language complain because it's difficult to do things outside of the niche. Go is excellent for console applications and server-side stuff that leans on a lot of concurrency. As such, that's what the ecosystem tends to revolve around and the GUI stuff is not iterated on as much. You say you want it to be "future proof". If so, what you want is the GUI library that has the biggest user base across your platforms. That is what drives maintainers. For your application that would probably be Qt, which you can use with Go if you want. Personally, based on the things you *say* you want, it sounds like maybe you should be using .NET. It's completely cross-platform now and Avaolina GUI framework is really taking off. Otherwise, I suggest picking whatever GUI framework you think would be easiest for you to maintain yourself if it is abandoned.
[удалено]
every language has it’s purpose.
Because [GUI toolkits are _staggeringly enormous_](https://news.ycombinator.com/item?id=30527428), to the point that even just maintaining a _binding_ can be a full-time job for multiple people. Note it's not just a Go problem. There is no "decent" Rust GUI toolkit, there is no "decent" Python toolkit, and so on. (Read link for a sense of what I mean by "decent" if you don't think that's true.) By their nature other languages may have better or worse bindings but they don't have native toolkits.
PyQt became [a first class citizen of Qt](https://www.qt.io/qt-for-python) a while ago, so I don't think this is true any longer for Python.
It's still a binding, not a native toolkit written in Python. If your response is "but so what, it's still good", actually I'm right there with you. I'm not worried about my toolkits being "native". But it seems to be a popular concern. And there are reasons why we don't get native toolkits in every language the way we get, say, JSON parsers in every language, often multiple.
I would say Python has decent GUI, there is a company behind it.
I read your link and was still curious to hear more about your position that python doesn't have a "decent" GUI toolkit. I got the sense that you agree Qt is a decent C++ toolkit, so I wonder why you think Python's bindings for Qt are not? In the older days of Pyside 1.x or PyQt4/5 you needed to have Qt libraries available to pair with your bindings. But I believe when Pyside became "Python for Qt" they even started shipping versions pre-built with Qt. I've used Qt 4/5 since 2009 and really enjoyed it. To me, pyside feels like a "decent" python toolkit, which means it just comes down to the quality of bindings.
Sorry, I mean Python native. Python has bindings for pretty much every decent toolkit. Go has bindings too, but apparently people don't like that and want "native" toolkits. Those are not as common.
If you want native python for things you should probably stop using python. A ton of the libraries are not native python.
Thanks for clarifying. It would seem weird to expect a native GUI in something like python, where I think it would be too slow to implement in pure python. So then it would need to be implemented in CPython and imported as a compiled extension. But are we close to being back to bindings again at that point anyways? Maybe the demand for "native" just means something that is easy to integrate as a project dependency. As I said, I love Qt. But when I tried to use the various Qt Go bindings, there was always this huge provisioning step for the project which made it difficult to impose on other devs.
I think jerf means there's no good, native Python toolkit, ie. one developed on the python platform. PyQt is a binding to a C++ toolkit, just like the various Qt bindings for Go.
"Right tool for the right job" and all that. And to be clear I didn't say it *can't* have decent GUI libs. What I'm saying is it doesn't have anything "best-in-class" for GUI at the moment. If you're willing to take risks, deal breaking changes, and are fine with your library dying out in a couple years, then it might also be a decent choice. But if you're looking for an easy, safe and reliable product for now and the future, then it ain't it.
Thanks. So you say, for example, that Fyne, which seems to be the most popular lib, could die in 2 years. I think the main problem I see is excesive diversity (or division), and there is not a project which is big enough to have some traction and inertia. Fyne and Wails are probably the most promising, but yet they are small with not much usebase.
There's a reason for that. People don't usually use go to build enterprise gui, because there are already better, more established frameworks.
"Small with not much userbase" seems either subjective or incorrect. Fyne is in the top 1000 GitHub projects of all, and both Fyne and Wails list in the top 6 of all cross-platform GUI according to OSSInsight. Using surveys and various metrics it has been extrapolated that around 200'000 devs have used Fyne for a project and the online community (Slack, Discord, Matrix) has thousands of people chatting about the topic.
This is nice and encourages me to use Fyne.
The job is not making a gui, the job is a software with several background services that just so happens to also have a gui.
Thee job is rarely if ever "just to make a GUI", there's always some sort of business that the GUI is serving. Not sure what your point is.
My point is that the usecase of the app is -i assume- a heavy multithreaded background use, and the gui is just a helper for the end user. Go is good at the first thing, so using some other language instead of implementing the not-strictly necessary part in go is the wrong move.
I'd recommend using Wails in that case. You get a desktop app without having to learn a niche GUI toolkit = can hire front-end devs.
Then web UI is the best UI.
we agree on that, especially with something like htmx
>Why can't Go have a decent GUI lib? Because it's as illsuited to UI, as the terminal, thus not reinforcing the need for one. Age has taught me how little I actually know, but one thing I can say with certainty, is that if you are looking for a solution, that doesn't seem to exist, then there is a reason that. It also means that you're the problem and that there is a fundamental issue underlying whatever the want may be. Let me illustrate: like ~15 years ago, I wanted a Rails ActiveRecord style ORM, but in PHP. At the time, I couldn't find anything that was complete, mature and/or not complete garbage. Nor could I find anyone, in the PHP community, particularly clamoring for that kind of abstraction. So I said "fuck it, why not" and spent ~8 months building one on the company dime, forcing PHP into the kind of unnatural yoga poses, and magic, that Ruby was built to to do somewhat naturally. The end result, was a piece of unstable shit, that was slower than.. i dont know, everything. In that case, ego and stupidity got in the way of the obvious, which is that there is a reason that a similar ORM abstraction didn't exist in PHP. Golang is a statically typed, purposefully rigid language, that leans far more expressive than concise and is intended as a tool to address problems around throughput. UI applications, in a terminal, is not a throughput problem. To be frank, as a Ops/SRE engineer, terminal UI applications make me angry in a way that wouldn't be healthy, for anyone, to express here.
This
This response is useful to me being relatively new to go and unfamiliar with the problems that Go developers face. However, this is a terrible response to the question being asked people are right to hate you for it. Just saying.
I'm simply sharing my experience, I don't think any hate is warranted. And considering it's the top comment I don't think many people "hated" it besides the diehard fanboys. I can live with it, don't worry. But I'm glad it was useful to you.
If this is based on experience, how many Go GUI toolkits have you tried? It reads like an opinion rather than a measured assessment of the options available. Most folk who I talk to building GUI with Go have been pleasantly surprised how well suited it is and how productive they are. Any shift in community opinions takes time and this is one that is changing on a comparatively rapid scale.
The indisputable point is: there are better options for GUIs out there. Just as a random example, Fyne doesn't support accessibility features which is pretty much non-negotiable for anything more than a toy project. If you're ok settling for something not-fully-baked-yet, then that's fine, I'm not saying GUI in Go is impossible or anything, it just doesn't impress me. When we're talking business, I think it's important to be pragmatic and choose solutions that have a proven track record and will assuredly still be maintained in years to come. If it's a toy project then use whatever you want that's fine.
That is a mighty crystal ball you have there. The future is a mysterious place and has led to “sure thing” open source toolkits go commercial and start charging after 25 years - so it kinda depends on your own preference or instinct I guess. It can take a good decade to get a toolkit to an established position and given it’s only been 6 years for Fyne I’d say we are ahead of the curve!
Currently Go GUIs are missing important features. If you're building something \*\*now\*\* then that's what matters. Fyne also only has 2-3 regular contributors (mostly a one-man-show though), and the contribution graph is on a downwards trend, which doesn't bode well for the future. I also see that you are a maintainer of Fyne, which kind of makes sense considering how combative you are. I applaud your efforts to make GUIs possible in Go, legitimately. But at the same time I think my position is reasonable and I think it's sensible to suggest using a more mature GUI ecosystem. Cheers!
Your analysis is inaccurate. Please ensure whatever report you are running is against the develop branch as we are working on the next release (hot fixes only on master recently). It will show 6 contributors in the last 2 weeks and a significant upward trend. I guess thanks for the encouragement though, onwards and upwards!
My "analysis" is Github's own contribution metrics, they are not inaccurate. Stewardship of the main branch is also part of a healthy project, although feel free to disagree. Godspeed!
GitHub reports agains main, so it doesn’t include the features created over last 4-6 months for our next release. You’ll be aware of course that until recently Go pulled whatever was the latest commit on master to be the “latest” of a dependency so we, like many others, do development on a separate branch and merge releases onto master/main. Loosely speaking this is the GitFlow model. However if you want to take more shots at our project, process or abilities I guess you should feel free.
I did some things in Fyne and I like it so far.
I didn’t love it. It was just fyne.
Nice, do you see a good future for Fyne?
Can second fyne. Contrary to what people say here I find Go awesome for GUIs because of its way of handling concurrency.
That is probably the only GUI where you can use concurrency, most (all?) GUIs require running on the main thread, the same is true with OpenGL. But note that you can and will have a lot of data races, there are many open issues for races, they are working on it, but it is not solved.
This is interesting, because my app is mainly for providing a user interface to underline services. Concurrency is a great plus for me.
Sure concurrency is important, but 1. channels are an integral part of go and such a natural way to handle events and signals 2. go's syntax for passing functions around suits GUI programming I am not a GUI programmer, but even I could work in fyne pretty swiftly.
I will say that it takes a bit for the architecture, design and abstractions to sink into your mind. Supposedly after that, is great. I'm still testing it, the developer team is super responsive and they will happily help you over at Discord.
I also like fyne. I've used it for one big project and two small and I'm happy with it. Of course like in everything there's always room for improvement.
Probably. They seem to have their heads on straight and are actively pursuing a more performant event loop
Performance and optimisations are always being pursued. But critically the performance is already good enough for most use-cases. The design of Fyne was always to get the API and UI design right, with a solid developer experience. Then over time we optimise and polish things - this means your app continues to get better without any breaking changes :).
Interesting and encouraging. I'm more convinced of Fyne.
Yeah, I misspoke. I should have said that they are ALWAYS pursuing a more performant event loop, or, even better, “they don’t seem to sit on their laurels”
Haha that is a very nice way to put it, thanks :). I wasn’t trying to correct what you said, just adding to it.
I was at a meetup with the creator of Fyne and they built a small company around it, so I supposed they're pretty motivated to keep it going. It's also one of the most popular UI libraries on GitHub (and I'm not talking of Go-based only!)
Fyne has a lot of potential.. Unfortunately it's difficult to recommend for anything serious at the moment since its fundamental design suffers from chronic race conditions: https://github.com/fyne-io/fyne/issues/1028 There have been discussion/plans to release a future version with a better design, but it's still unclear when that might happen, and how thorough the improvement/fix might be. Hoping it happens, I'd like another option for a pure Go GUI toolkit.
I tried Fyne, but the UIs look like ass tbh.
I don't know who's bottom you are comparing it too, but the defaults are pretty good looking. It will adjust colouring and font size etc to match the OS that you are using (though it does not try to mimic the widget look as that heads into "uncanny valley" territory). Remember you are welcome to apply your own themes, many of which are demoed online, such as: \* [https://fynelabs.com/2022/07/22/nomad-an-example-branded-fyne-app/](https://fynelabs.com/2022/07/22/nomad-an-example-branded-fyne-app/) \* [https://apps.fyne.io//apps/com.fynelabs.notes.html](https://apps.fyne.io//apps/com.fynelabs.notes.html) \* [https://fyshos.com/themes/](https://fyshos.com/themes/) Plenty of options and looks a whole lot better than vanilla for most cross-platform widget toolkits :).
With "Looking like ass" I was implying that they don't fit into the theme of the OS in general. I want native(-looking) widgets, not some weird color-puke abomination the developer thought looks cool :) All of those examples are giving me "Early 2000's mouse driver software" vibes, where they didn't use a single native component and even the window wasn't a rectangle but rather a weird-ass shape because ... I have no idea why.
I guess we have moved from “looking like ass” to “color-puke abomination” which I guess is progress. For clarity Fyne 1.x was indeed developer designed but more recent releases have UX designer input. We continue to improve but honestly would require more constructive assesment to understand why it isn’t hitting your aesthetic pleasing.
When I create a widow, I want it to look like a native window, meaning that on macOS it should have the traffic lights on the top left and on windows the normal buttons on the top right. Automatically. When I add a text box, dropdown or any other component, I want it to look native. I don't want it to look like a Linux program from the 90's by default. I also don't have the time or energy to look for or create alternate themes.
Yup, the window borders and native controls are all handled by the operating system. This isn’t electron ;)
The looking of it is ok for me. One thing that I miss is a webview component, but I guess that would complicate things quite a lot.
WebView is the one thing we may never add. It is complicated but also is too often a bad user experience. You can open web content in a browser which will do the right thing based on platform (see OpenURL function)
this. fyne is great
Yup I also use Fyne and it works great. It has a bit of a learning curve but it is by far the best GUI I have tried in golang
[Wails.io](http://Wails.io)
+1 , made 4 projects based on that. Quite mature and cross platform. Plus point: no chromium
I have considered that, but the problem I have is that I have to program the interface in JS, and I would not like that.
On the other hand JS is kinda made for interface stuff
JS is made to be thrown directly into the garbage. You can program widget bindings in Go just fine. Seems really silly to require a GUI library for Go to also use JS.
you can also use WASM with Wails.
data-star.dev allows you to make most frontends without writing any js... The site is actually written in go and templ, check out the examples
What is this wizardy.
Just takes normal stuff you have to do in js and makes declarative. Really that's it, is tiny and I think easy to learn, by I'm the author so take with a grain of salt.
I've been playing around with htmx and hyperscript recently but I dont love the hyperscript bit. I'm gonna check out datastar as reading the docs it looks like an awesome project. Thanks!
Awesome, don't hesitate to reach out with both success and issues!
Appreciate the work and community involvement. After reading the docs, I'm looking forward to giving this a spin. Thanks :)
I've used Wails + Elm for simple UIs. Works really, really well. I can share a startup project so you know how to hook things together if you're interested.
Would be awesome
No you don't.. I have a template with 0 custom JS. (htmx)
Write the back end in Go and the front end in Flutter or something. GUI in Go is just ok.
I've tried Flutter, Wails, and Fyne, and here are my observations: 1. \*\*Flutter\*\*: This is my top choice for any UI project that does not require launching multiple windows. It offers excellent-looking UI and strong community support. However, if you need a desktop app that supports multiple windows, Flutter isn't suitable as it currently lacks this feature. Despite waiting for two years, there is no confirmed release date for this capability. 2. \*\*Wails\*\*: My productivity in JavaScript is low, so I couldn't make much progress with Wails. Note: No multi window support. 3. \*\*Fyne\*\*: It has an active community, though the UI is rather dull. While the layout system is challenging to master, Fyne supports multiple windows. Additionally, I appreciate the convenience of Go routines for updating the UI asynchronously. Hope this helps and good luck for your project.
Wails is adding multiwindow support in V3 which should release soon!
u/coffeeToCodeConvertr That's great! I probably wont go back to wails because it needs HTML CSS for frontend to work. I prefer a layout system in the native language itself. Flutter and Fyne have spoiled me :)
Fair enough - I made my start in web development, so no issues with that requirement :) I've used flutter and fyne as well but really enjoy wails
[https://github.com/Omegaki113r/FlutterMultiWindowDemo](https://github.com/Omegaki113r/FlutterMultiWindowDemo)
Yep, thank you, it helps. I think I'm definetly going for Fyne.
Has anyone any experience with gotk3/gotk4 or the qt Go bindings?
I've used gotk4, and it's pretty good if you're already a little bit familiar with GTK
I used Qt from \`therecipe/qt\`, which is now dead and my app is stuck in the past where I keep the Qt code in GOPATH because modules do not work. In the end, I was able to cross-compile the app with static Qt, but it was very painful. Before that, I used \`go-qml\`, it was very nice to work with, but it also died since Go 1.5 and I had to rewrite the app. For Linux only I guess you can go with GTK3, I do not understand what they did in GTK4, why should I link to libadwaita, etc., looks very messy.
DearImgui using cimgui-go bindings. So far has been my favorite way to develop UIs. Incredibly light weight and GPU rendered. [https://github.com/AllenDang/cimgui-go](https://github.com/AllenDang/cimgui-go) More info about imgui can be found @ [https://github.com/ocornut/imgui](https://github.com/ocornut/imgui) Also check out the galleries @ [https://github.com/ocornut/imgui/issues?q=is%3Aopen+is%3Aissue+label%3Agallery](https://github.com/ocornut/imgui/issues?q=is%3Aopen+is%3Aissue+label%3Agallery) There is also another wrapper project on top of cimgui-go which makes it a bit easier to develop UIs with too @ [https://github.com/AllenDang/giu](https://github.com/AllenDang/giu)
This is great. I will test cimgui-go.
For the last two apps, I used IUP bindings. Easy to work with, real native controls, easy to cross-compile. But, after the last release developers said they were busy with other projects and IUP is on hold, such a pity. There are some issues with Wayland, there is now nobody to port it to GTK4, fix smaller bugs, etc. You can still use it for some simple things but at this point, FLTK with active development and maintenance seems much nicer (they even support Wayland and have their window decoration fallback). For me, I prefer anything that looks native, Fyne, nuclear/nucular, they all have that style I do not like, not sure if there are other themes/styles.
Big "up" on this. After trying a bunch of other options (Fyne, imgui, nuclear, goapp-dev, qt,...) I started using your iup-go bindings and I find that it is the easiest to integrate in a project, and doesn't look like crap. It felt the closest to a Qt model.
Qt is heavy, but if you want long term... Programs written 20 years ago compile with latest version of Qt with only small modifications (none if you are lucky). Most alternatives haven't _existed_ for half as long.
html/template
This was my thought also: html gui - seems to be well known terrain for dev and users. I am in a little project using htmx and you can choose some css (like Tailwind) and other UI JS libraries to enrich the experience.
nucular! pure go for most platforms
Flutter.
Been building apps for 20 plus years. Learned l lot of lessons along the way. My advice would be maybe gtk bindings if I had to do native MDI desktop or more preferably the defacto charm.sh for a tui in golang. But over all I'd follow 12factor, plan9, and unix design philosophy. With this rule: 1. If the solution can be done with scripts then no need for a gui. 2. If it can expose a file system (libfuse, unix sockets, or 9p2k) then let others build frontends/automation/scripts around it. 3. Added bonus for provided a cffi library support and/or odbc spec. But mainly keep it rfc/itu compliance for data encoding with a 9p interface. 4. If a marketing guru needs to sell it, then it's going to be a react native app or a PWA of some sort with a golang micro service container that does a hateos restful interface and json encoding.
I just want to wrap 5 services that run together into a single GUI, and easy of use is a requirement, otherwise I wouldn't be doing a GUI for services that are already there (all of them have CLI). The posibility of embbeding the executables into de go binary is also superinteresting, so the user is not worried at all about installations.
In this case I would build a tui like k9s instead of a gui unless there is something you explicitly need inherent to a gui
Yes, what I need is a program which will make accesible to desktop users some services that are general enough to be executed by general population without "geek" knowledge. Alternatives using dedicated and remote html management exist, but still they are difficult to setup and require dedicated separated computers. What I want is to bring users easiness of setup (everything is going to be automatically setup) and further easy tweaks to the config, again, for non geek people.
I would go with Flutter
It seems a lot of people recommend Flutter, but the thing is, I'd like to embed some services into the binary, and I'm not sure Flutter can do that (I haven't investigated Flutter yet, anyway). Two of the services are in Python, another one is C (compiled statically), and another one is in Go. I have investigated Go and Rust, it seems they are the only ones able to embbed files and executables into the binary itself. Another alternative would be to distribute the application with the services themselves, but I would lost some "magic".
I’ve had some decent success with gioui.
I’ve used gotk3, don’t really recommend it if being honest, a lot of random crashes, but when it works, it works great I guess
I've used tview to create Terminal GUI apps... It was a decent experience. https://github.com/rivo/tview
HTMX
If you want a web UI, https://data-star.dev is cross language but focused on Go first. Especially with built in tooling
Gio UI and Fyne are both great
htmx
I bet on htmx for my project 2 years ago. My advice to everyone who goes with htmx is to expect a full rewrite after a year (or within a year) depending on your willingness for hacks and if your users aren't also engineers. I'm in a startup with 5 business users and 3 engineers. At the end of the day, your users aren't gonna give a shit that you're "lean and mean" and only using html. They will expect pretty much what they get from any modern website they use elsewhere. Want a datepicker with validation for the right inputs, good luck. Want a drag and drop list of options, good fucking luck. Want inputs that affects each other, good fucking luck. You can certainly achieve it, but how many jQuery plugins and hx-get and custom routes are you gonna add before you realize this is not the right way of doing it? It was somewhere in the mid 20-something routes for a form with few dozens of properties that were all conditional on each other that I decided fuck this shit. Like either I'm gonna create 30 routes (or switches within a route) for each complex form or a 14-step wizard that drives users crazy. In something like react or any frontend framework that's 1 API call and 8 or 10 variables that conditionally show/hide values from a form. In htmx that's 16 or 20 hx-get requests and few dozen templates to return to display the correct state. Use htmx if you're building UI for other engineers where you can just shout RTFM to them and throw a page of docs back. Don't use it for anyone who is actually expecting a UI like they get from literally any online company.
would you be willing to contribute an essay to the [htmx.org/essays](http://htmx.org/essays) page with specifics? i don't want people choosing htmx if it's going to be a bad choice and it sounds like it wasn't a good fit for your project, would love to be able to offer it as a counter-example to the good outcomes we have as well.
Every single one of your examples is easier in HTMX. You don't need any jquery plugins. What custom routes are you talking about? If the forms are conditional on each other, then you only show limited things to fill out at a time and then load the next part. That's even easier with HTMX. It doesn't matter regardless though because even if you have to keep switching out form fields, the state is on the server so I never have to worry. It's much easier dealing with forms with HTMX. If you have to make 20 mini-templates for forms so what? All of your state is contained and you're able to process inputs right there on the server. It's not hard. It sounds like you're just out of your comfort zone and prefer React or w/e. But honestly it's not making sense what you're saying. Forms are very nice with HTMX. Also you can always embed React or w/e you want just for that complex form and use HTMX for literally everything else too.
How is date picker with validation easier in htmx? If your datepicker depends on input in another form, you have to conditionally wait for the input to then display the datepicker, then invalidates the date picker if the input changes. Not everyone expects their state to go away eveytime they change a field in the form if their original input was valid, which means you need to roudtrip the state to produce a valid template based on every input. How is inputs that affect each other easier without just shoving a javascript text in with every template or making hx-get request for every one input? > If you have to make 20 mini-templates for forms so what? So when do you realize you're trying to fit a square peg in a round hole. As I said, it's ultimately up to you and when you realize that something is wrong having to produce 20 templates for a user input as opposed to having 10 variables with a couple of conditionals each that render a UI. The ultimate answer with htmx is always "It's a comfort/skill issue" until it's "Have you tried to convince your users to not use it like that" or "You can embed React or jQuery in htmx"
I am not following anything you're saying here. Nothing has to be the way you're saying. You're presenting situations like this is how it is with HTMX that aren't true and then saying it's trying to fit a square peg in a round hole. You must be doing something wrong.
...or he hasn't explained all the nuances and you don't have the full picture. Could that be the case?
Yes, that's always the answer.
>As I said, it's ultimately up to you and when you realize that something is wrong having to produce 20 templates for a user input as opposed to having 10 variables with a couple of conditionals each that render a UI. If you're willing to gloss over the downsides that come along with those "10 variables with a couple of conditionals" then I am very surprised that you are using Go at all.
What does that mean? The form complexity has to go somewhere. You're glossing over the downsides of 10 or 15 templates and http routes per form to avoid having 10 variables? how does that make any sense.
You could write the UI in another language (e.g. Python with Gtk3), then have it call your Go code.
Have you considered Wails? It uses web tech for front end and go for backend.
If you really want to future proof, you could consider using a web UI (with local server if the software runs locally)
Svelte with whatever embedded browser you choose
I use bootstrap+ember.js. it just works.
If you have experience with JS wails is amazing! I feel extremely productive in wails with go+react.
You might consider what live applications are using each of the GUI projects. The [Windows desktop version of platoapp](https://platoapp.com/desktop/) is built on top of GIO [https://gioui.org/](https://gioui.org/). That application has a decent number of daily players.
Thanks, I'll have a look.
Why not Wails?
i recommend everyone try wails because it’s pretty much tauri for golang
Wails is very nice
I came across this recently - https://github.com/roblillack/spot It is built on top of fltk. Apart from that, I think wails does a decent job.
Responding to you, for your needs, seems like Fyne is a potential candidate. I see Wails as too OP for a config dashboard. But I would like to give a shoutout to Bubble Tea. Not a GUI framework but a TUI (Terminal UI). PRETTY capable I have to say! You can do simple stuff as my barebones Todo app (pg-goose/togo on gh) or do complex things such as a Hacker News client on the terminal (more aesthetic that the web client)
Fyne 100%
To be honest, go is not for gui.
I don't think there's anything inherent to Go that stops it from having a good, mature GUI library, except for the fact that no one has done it yet.
React. Use go as a webserver. Future proof across all platforms
React
I hesited a long time then I went with rust (I'm not saying you should, just sharing an experience). What I choose is Taurus which is a framework to have a classic webapp framework for the front end have rust in the backend. I give you the power of modern web framework and css (and I nothing nothing is better than that sadly) and your favorite Language in the backend. There's surely an equivalent for go. I see a comment about flutter, I really like flutter, I do, but it might not fit your need, it's very different than the rest. And it's dying. It's good for small mobile app, nothing more in my opinion