Hacker News Reader

Indeed, however I think we might replace Go with any programming language and your comment will still make sense. Currently, web-browsers are the best have-it-all platforms, and outside web-technologies there isn't many good alternatives. We landed in 2020 and we don't have any complete, native-like, cross-platform GUI toolkit (if we skip Qt and GTK).

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

[5]: https://github.com/Immediate-Mode-UI/Nuklear

[6]: https://github.com/rxi/lite

Funny how i have visited almost all of your links before. Do I understand it correctly that rxi/lite is just using plain SDL2 underneath to render the UI, do input processing, windowing,..? They must have had a lot of work implementing all of that. I always wondered why there are no well known ui frameworks on top of SDL.

Yes, that's right. To be honest, I spent some time already to inspect and analyze its code, because I found it as a nice example to learn Rust by rewriting this project.

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...

[2]: https://github.com/franko/lite-xl

[3]: http://antigrain.com/

> We landed in 2020 and we don't have any complete, native-like, cross-platform GUI toolkit (if we skip Qt and GTK).

So we have QT and GTK ...

> The "old" frameworks such as the GTK bindings are either unmaintaned or not complete or both

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.

Interesting.. I would have sworn that I just visited the gotk3 Github page and the project was archived.. very strange.

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.

GTK3 and Go work pretty well. Nice article about it here with example code: https://sudonull.com/post/12576-GUI-on-Golang-GTK-3

> With Go the only "possible" way is to write a server and open a tab in your browser.

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.

I agree that can be a viable solution. Mainly if the backend is also used without GUI. However what I meant is that the Go part of the application will be only the server part.

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?

> However what I meant is that the Go part of the application will be only the server part.

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.