In last years a lot projects have appeared, which were trying to compete in GUI toolkit market share. All of them had its scope limited, however they brought quite fresh look on declarative programming interface [0][1], superb 2D rendering pipeline [2][3], ease of embedding [4] and adaption to low-power devices [5] but none of them is "complete".
Personally, I am amazed of the implementation of rxi/lite [6], which is just an app (C with Lua) based on SDL2 library. It uses 2x less RAM than sublime on 1GB file, has lower latency, covers clipboard, keyboard, mouse, drag and drop, some context menus but does it feel native? No. Among many issues, it is easy to report an error with screen-reading software but it is quite common problem in all aforementioned.
Perhaps in future, something like LSP specification will see a daylight, which in outcome will helps us to provide universal, modular, limited to certain scope libraries that can be easily plugged in case of need. Maybe then we will came closer to "native" GUIs. In my experience, there are numerous developers who were trying hard to deliver "complete" GUI toolkit but have failed.
[0]: https://github.com/cycfi/elements
[1]: https://flutter.dev/
[2]: https://github.com/linebender/druid
[3]: https://github.com/servo/pathfinder
[4]: https://github.com/ocornut/imgui
rxi/lite have tens of functions in C to provide operation of file-system, implement fuzzy-finder or simple rendering calls for rectangles. Rest of code is written in Lua that shares a lot of signature-compatible functions with Sublime Text API. There is only Lua, STB (stb_truetype) and SDL2. Also compilation script is basic shell script [0].
It is also worth noting there is interesting contribution to provide sub-pixel rendering [1] (now, a fork [2]) which includes usage of libagg [3].
[0]: https://github.com/rxi/lite/blob/master/build.sh
[1]: https://github.com/rxi/lite/issues/145#issuecomment-64155409...
So we have QT and GTK ...
gotk3 is maintained and most of the widgets are in place (technically it's not "complete", sure, but still).
My biggest gripe with it is that the whole documentation is just absolutely useless string of "this function is a wrapper for this function in C" over and over again instead of it being, well, the documentation for the function that is being wrapped.
But good to know. And yes I forgot to mention the documentation.. you are absolutely right.. so far I have had that experience with all things GTK.
That split model isn't limited to browser tabs. You can write a nice GUI (native, or tooling of your choice) that communicates with your go back-end via API bindings.
This model is well proven (dockerd/docker cli; various crypto wallets and their front-end UIs, etc), though attention needs to be given to security concerns. Running a local service means malicious software that knows about the service could access it without the user's knowledge if you're not careful, exposing private or sensitive data that the service has access to.
Can you clarify these security concerns? If the server is only listening on localhost I don't see a difference to "the classic desktop application". If the malicious software has access to your system the data is always endangered right? Or were you talking about services that are exposed to the outside?
That's what I meant as well. You have a go daemon/service running that does the heavy lifting; and your front end (whatever it may be) knows how to talk to it. The UI elements remain separated from the work of the daemon.
The browser-based/localhost approach works well for this too, but you can also take the same approach for rich/native client apps without having to make the daemon platform-specific.
> If the malicious software has access to your system the data is always endangered right?
This is what I was referring to - nothing new, but IMO worth mentioning in the context of setting up a new service to run on someone's system.
The "old" frameworks such as the GTK bindings are either unmaintaned or not complete or both. The new frameworks like Gio and Fyne are promising but not there yet. Maybe in 1-2 years if they are being worked on consistently.
I really wish to do my upcoming project natively in Go (also Rust would be fine) but I don't see how.
Regarding web technology as desktop solution: all of those solutions including Go are just a mess IMO. They force go into the stack even when it doesn't make sense. Write the frontend in Go, compile it to WASM, wrap it in some browser.. it's just more complexity for no real gain.
There are some promising ideas, such as webview and wails but again not production-ready.
My conclusion: if you are willing to use web technologies, just use electron at the moment.
With Go the only "possible" way is to write a server and open a tab in your browser. But if people would accept this as desktop solution is another question.