Didn't read the book but I had a looong look at all kinds of "native" Go Gui toolkits and have to say there is none ready for professional / commercial cross-platform GUI applications.
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.
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.
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].
> 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.
> 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.
I would argue that Lazarus is a lot better than Go + QT on many counts - including the fact that it is completely free and you don't have to get an expensive QT developer license.
Think Visual Basic but cross-platform, with a much better language and component architecture.
You can develop non-trivial apps in hours rather than days.
The IDE is here: www.lazarus-ide.org
Why Lazarus?
* Has a proper Rapid Application Development (RAD) IDE with visual layout, event handlers, component tool bars etc and also built in documentation
* Extremely fast to develop on: The IDE starts in a couple of seconds. Compilation to native binaries in seconds.
* Cross Platform - Windows, Linux, Mac OS and perhaps even Android
* Binaries are really fast
* Excellent set of visual components
* Excellent set of database components including grids, CRUD toolbars etc
Lazarus is fine and good, but what does it have to do with writing UIs for Go apps? Can you integrate Delphi/Lazarus code together with Golang code in some meaningful way?
Yes? It supports different calling conventions. Easiest would be exporting things cdecl from Go. But usually the better way to do this is to write the UI in FreePascal (or something else) and use some form of IPC like pipes or network sockets to get the data to the UI.
I've actually done this, it works well, and the Lazarus GUI libraries manage to get a natural look and feel on all platforms.
If you want to build a good cross platform app, create some shared core and then separate, platform-specific UIs on top of it, using each platform's native capabilities.
People don't automatically deserve payment for the "fruits of their labour". Only if you use it and can't find a better/cheaper alternative.
What the parent suggested was not using QT and not paying the company that makes it, but that its price makes it unusable for their purposes.
(Now, that might have been based on a misunderstanding of the licensing involved, but ignoring that, the point still stands. If one had to pay $5000 for a GUI library, and one didn't have $5000, then one could look elsewhere...).
It would be misleading to call Qt the fruits of the labour of (the current) Qt Company.
It is licensed under the LGPL though (however much its current owners may want to change this, they can't because of the KDE Free Qt agreement), which means you don't have to pay. All you have to do is dynamically link to the library instead of statically linking.
It is surely more than those leeching Qt for their own projects.
The major contributors for Qt have always been the same regardless of the legal name of Qt owner.
It is quite easy decision process, don't want to pay for Qt's development, use LGPL and GPL variants earn as much money as one is willing to give upstream.
Decide to go commercial, then pay accordingly upstream.
I think you misunderstand me, I think the LGPL is a perfectly good license for Qt and I have little sympathy for those who aren't willing to abide by it (not least because Qt is a rather large library, and there's no excuse for every application to load its own copy).
> Decide to go commercial, then pay accordingly upstream.
Hmm. The commercial license actually prohibits starting development under one of the open source licenses then switching to commercial. If you start under an open source license, you'll need to abide by the LGPL if you decide to go closed source (and of course what you've already released remains open source).
The small business license is $499 and you only have to pay that if you want to statically link against QT without dealing with the LGPL. Dynamic linking Qt is the default, costs $0 and doesn't incur the wrath of the LGPL.
Is that $499 per platform? I'm using Lazarus right now (after QT sticker shock). It's pretty good and free. I rather like object pascal. TMS has a webcore product that runs out of Visual studio (non free)
which is also object pascal and generates an html/js SPA. i'm not affiliated with them at all. Just a fan.
I just recently tried webview/webview in Go and was a little fed up with the fact that it could not be a single-binary plug & play experience on Windows. To that end, I am working on an experimental alternative that uses Webview2 directly without CGo: https://github.com/jchv/go-webview2
It still requires WebView2Loader.dll, but I am working on another library so I can just embed it directly into the application, and that work is happening over here: https://github.com/jchv/go-winloader
Sorry for the blatant self promotion, but I thought fellow stubborn people might have a desire to drop to as few dependencies as possible. I prefer building without CGo. The only downside is there’s not really a great way to fall back to EdgeHTML so users will need a Webview2 install, and right now Windows isn’t shipping it, but I think going forward it will be reasonable to just link users to the webview2 runtime page to go install it.
(Also, it should go without saying, but this approach only improves things on Windows. You will still need other bindings for other platforms.)
I like the approach of go-winloader, I'd be happy to include an example of using it with webview into the readme. I agree, including 2 DLLs on Windows is ugly, however I believe that using CGo for webview would be a long-term win, because new features of webview may emerge in webview.h and they will be available in all language bindings immediately, including Go. I might be wrong, but I think if there is a solution to include both DLLs (webview.dll and WebView2Loader.dll) into a single executable in Go - that could simplify life for everyone.
Honestly, if you embed both DLLs, the only thing preventing you from being able to build with CGo off is the bindings implementation since it relies on CGo features.
However, it might be possible to have one’s cake and eat it too here, if there is one implementation using Windows-specific Go features that embeds the DLLs and one implementation that uses the existing CGo approach on other platforms. Essentially, the binding to webview.h would be abstracted away from the Webview Go interface implementation.
I will continue to work on go-winloader in my spare time, and hopefully will have an interesting webview pull request in the near-ish future.
Windows-only; Windows is really the only platform where I am concerned about making the binary very self-contained anyways. On Linux/BSD package management makes the GTK-based solution pretty reasonable. On macOS I think the webview/webview solution is already self-contained.
What I'd like is to help make upstream webview/webview more self-contained somehow, but for now a possible approach is to just use go-webview2 for Windows and then webview/webview for everything else. My approaches to lower dependencies may not be accepted upstream webview/webview: direct bindings to Webview2 mean no EdgeHTML fallback + code duplication from the C bindings, and go-winloader is (WIP, it doesn't even work yet) a fairly complex piece of code that would be an additional dependency.
(Just so it's clear, I do actually want to make a concerted effort to try to support an EdgeHTML fallback, but it will effectively be based on directly binding to MSVC ABI from Go, and therefore will be a lot uglier than the current Webview2 code that just deals with COM interfaces directly.)
People complains about this setup but WASM is optional. I've been using Golang with Lorca without WASM. I actually don't see the value of WASM here.. Anyway, I used Svelte on the frontend, pretty straightforward but any other lib would have been as easy to bind. And it just... works.
The main advantage over Electron is the size of the bin (~20MB for a medium app vs. >100MB if it was Electron). If you know the people who are going to use your app have Chrome installed, it's definitely better than Electron and you get the best of both worlds - quick crafted & beautiful UI and performant backend
Sure you have the smaller distribution size. However you also have drawbacks. As you mentioned Chrome must be installed. Then you can not guarantee the Chrome version like this.. maybe the version the user has breaks your app. Also you cannot use the "native" menu and other windowing features as you can with electron. I am not really convinced by the "Lorca concept".
My problem with these approaches, is what's the next step? Do you implement GUI buttons on top of canvas and push pixels in WASM? Do you try and do something like ImGui and use WebGL? None of these approaches are efficient. If you are making a native app because it would be more efficient, I'm not sure what the point of this approach is.
In the their linked previous article, they also considered Electron. So the motivation is probably not efficiency. There are many other possible requirements that get you making native apps.
It uses native webview so no electron. Let's you effortlessly bind JS functions to those in Go.
V2 is in the works and will effectively bring the best features of electron window management (menus, frameless windows, drag regions etc) over to native webview.
Currently uses IE11 on Win 10 but V2 will only support Edge so you get WebKit across the board.
I am only familiar with Electron (due to its hype), what is native webview, is it like a browser? If yes why is it better? Asking as someone who has never developed any desktop apps.
It's a minimal native application which creates a window with an HTML widget in it, essentially a mini-browser wrapped in a native application. The difference to Electron is that this browser isn't a bundled Chromium, but the browser engine that's integrated with the operating system (Edge on Windows, WebKit on macOS and Linux), so the application installer is much, much smaller.
When I tinkered with https://github.com/webview/webview on macOS a minimal Hello World application was around 26 kBytes (kilo, not mega), which is about 7000x smaller than a default macOS Electron instance (173 MBytes).
The downside is that as the application developer you no longer can control the browser version your code is running on, so you may need different code paths for WebKit vs Edge, or old vs new browser versions, but this is the same problem normal webpages have to deal with.
But at least you can call out into native code and native operating system APIs, unlike "real" web applications.
It uses what is built into the OS, the native UI control which renders web pages. It doesn't need to download a whole 200mb Chromium or anything like that.
So your binaries can be really small too. Seems like faster start up times also.
Not related to "native UI" vs browser, but still an important distinction:
Unlike Electron, Webview does not embed a browser, but uses the platform-native browser engine. That's Cocoa/WebKit on Mac OS and Edge on Windows. Since Linux doesn't have a one, gtk-webkit is used there.
This allows for very small binaries, but necessitates dealing with the platform incompatibilities.
Building native UIs cross-platform is a huge PITA and frequently the frameworks are also very annoying to use. I don't condone the use of browsers for desktop software because it is a travesty, but it is very understandable when you look at how we got here.
I've used wxWidgets, Qt, etc. using several languages, on several projects, and haven't really had any major issues.
Given this experience, I just don't get how cross-platform UI-frameworks are somehow a bigger PITA than pulling in and involving a whole other set of technologies.
Nobody can program using a framework that may one day support their OS. It's either real or it is not and currently this is not real, just an empty bag of not even promises.
There are three problems. One that even with the resources MS has at it's disposal it's taken them half a decade to make their framework cross platform. Second it makes sense for them to target the big three that represents 95% of the market. And Linux desktop isn't one of those. And third the Linux community is hostile. Back in 2010 they could have embraced Mono which was sorely needed but didn't out of just spite.
Brings up a third point when talking about development. Microsoft is providing a posix compatible dev environment under Win10. The threat that poses is completely unappreciated.
The open-source community doesn't like Microsoft because Microsoft is hostile to open-source. It's their MO to embrace things first and people with short memories laud them for it every time. It's very disingenuous to quote their hostility as one of the problems when really it's a logical historical development. They're going to have to put in a lot more effort to make amends for all the terrible things they've done over the years.
But all of that is really beside the point. Saying the "community" needs to fix it means they won't put time or effort into doing it themselves, which by extension means the integration will most likely never be as good as what they have prioritised. This will relegate their "cross-platform" solution to the realm of all the other frameworks: Bad.
Browser-based apps get you a lot more flexibility and it's much easier to find developers for it.
I mean ideally you'd create a native application for all operating systems and use their native frameworks, but you need to hire at least two developers (for redundancy / knowledge sharing) per platform and it'll be a constant struggle to keep features aligned. It can be done, but you need a clear vision, alignment, some independence for the native app developers, etc.
But it's pretty much unfeasible for solo developers.
There are frameworks, such as Qt and wxWidgets (desktop), that offer native or near-native widgets for all major platform.
Given that most of these have bindings to many languages, I don't understand why one would involve a browser-runtime and whole other set of technologies.
Can you give some examples of a Qt app that looks native or actually looks good?
Two Qt apps that I use are Calibre and Ripcord, the two ugliest apps on my computer. Not that I'm complaining, but never lines up with HN's why-would-you-use-a-browser Qt praise.
Wireshark, TeamViewer, Parallels Desktop for Mac, etc.
For more, see [0].
The fact that it's possible to not build an "app that looks native or actually looks good" doesn't imply that it's impossible to build one that does, though.
And I actually tend to prefer wxWidgets, as this wraps the platform's native widgets proper, whereas Qt reimplements many (all?) widgets, but attempts to offer a native look-and-feel.
Regardless: Actual GUI-frameworks have huge advantages to using a browser, like:
- Better performance
- Visual and UX consistency (HCI, people!) on a shared platform
They are paid to work on whatever platforms the customer is hiring their guns for.
And again we managed as solo developers, or with very tiny teams to do that in the context of 8 and 16 bit home micros, which meant writing lots of Assembly and hardware specific code in the process.
So I guess strangely younger generations cannot manage to go to school bare foots uphill in snow both ways.
I generally recommend Sciter for desktop apps; The programming model is extremely intuitive and straightforward, and in my experience, the performance is excellent. Besides that, I'd look at something like webview
Yup, it renders correctly out of the box. Occasionally some small odd quirks with more complex CSS styling though. I've done lots of development with Qt and webview but saw significantly better performance in Sciter.
Well done, I too am building a desktop app in Go, I couldn't find a decent GUI library and just resorted to packing a webserver & static files into my program instead. For the time being anyway, still looking for Gui options. Figured I could make a creative html/css UI instead of figuring out how to create a GUI. I'd like to mess with Qt but the GUI builder is with their paid licensing iirc i think, but it seems to be the only cross-platform solution afaik
> I'd like to mess with Qt but the GUI builder is with their paid licensing iirc i think, but it seems to be the only cross-platform solution afaik
{apt, brew cask, choco} install qtcreator
it's entirely free & open-source. there is Qt Designer Studio which adds a couple of convenience functionalities if you are making e.g. embedded appliance dashboards but for 100% of desktop UIs you have everything needed in the LGPL qtcreator
WASM give us an incredible amount of new possibilities and hopefully, we will get to a point where Go will be used in production also for GUI/apps purposes :)
Hey, I love your go-app library! I wrote a blog post using it here https://maori.geek.nz/a-web-app-using-bazel-golang-wasm-and-... and have used it on multiple small experimental projects. I have plans to use your code, either as inspiration or direct dependence, for many of my future projects! Cheers :)_
Knowing next to nothing about Golang: Is it unlikely that someone would ever develop an actual desktop toolkit for Golang? If so, how come?
From a naïve point of view, it would seem like overkill to run a whole web browser when a few kilobytes of memory is all it really takes to draw a widget on screen.
Cross platform UI toolkits are a sisyphean task that everyone wants someone else to work on.
Platform vendors like Apple, Google, MS don't want to let developers target multiple ecosystems - they want a monopoly on devs and users, hence the endless churn of languages, frameworks and SDKs, making it difficult to keep up.
It's much easier and more reliable to use HTML, even if the experience isn't as slick for users.
> Platform vendors like Apple, Google, MS don't want to let developers target multiple ecosystems
Is this actually true? As in, I see how we may arrive at the same outcome anyway, but at this point, do those companies actually care about aggressive lock-in?
- Apple seems to be more ignoring the possibility of SwiftUI on other platforms rather than actively preventing it since https://github.com/Cosmo/OpenSwiftUI (dead) exists. Sure, they will never help to make it happen, but "don't want"?
- Google is pretty much cross-platform/-ecosystem with Flutter which explicitly supports iOS.
- MS seems to have given up with Win Forms opensourced and working on .NET Core / Mono.
"MS seems to have given up with Win Forms opensourced and working on .NET Core / Mono."
MS does not care what OS you use anymore. They want users of all operating systems to order their Office 365 license and run all their cloud compute loads in Azure.
You won' probably catch any exec from MS and Apple admitting the obvious, but it's really against their best interest to encourage multi-platform apps as this would give users a choice between operating systems. It's not something that is discussed a lot these days because modern web apps are quite powerful, yet it's clear a good quality multi-platform toolkit would be a boon to users and developers alike.
As for MS open sourcing .NET Core it's all good and nice, but WinForms and WPF are still Windows-only, and according to MS they will remain this way. And Apple has no intentions of doing the same with SwiftUI.
"Support for Winforms 1.1 and 2.0 has been completed, and is now in a maintenance/bug fixing state."
"System.Windows.Forms implements its own driver interface to communicate with the host OS windowing system. Currently, we have drivers for X11, Win32, and macOS. These drivers translate the native window messages into WndProc compatible messages, to provide as much compatibility with native .Net as possible."
To clarify: you can't use Windows Forms directly with .NET Core on non-MS platforms - you nee to port them to Mono.
I tried to use Mono several times, starting from Ximian and Xamarin times, and I always encountered strange problems that were not present in the original applications. I hope they improved somewhat recently because the code produced back then was often unusable (e.g. huge leaks after a couple of hours of use.)
While the backends are unified, MS still do refuses to fix the UI framework. They instead have yet another version of the post WPF scrambled egg UI framework. AKA WinUI3.
the native grumpy old people like me will continue to use Windows forms or WPF or MFC,ATL,Win32.
The masochists will try to use the open-source silverlight replacement. Moonlight?
The futurists will use Avalonia. Maybe SAFE stack MVU via Fable?
The Microsoft contractors will use WinUI3.
Vast majority of web developers today will use electron, as unfortunate as that is...
Mono is not meaningfully cross platform and is not the official Windows SDK.
The iOS SDK is not cross platform and changes frequently leaving behind it a trail of dead x-platform projects like the one you cite.
I suppose there are multiple reasons for this lack and it may not be a deliberate strategy in all cases but there is no incentive to promote cross platform work and there are multiple incentives for corps not to. These platforms are made to corral users and devs, not to share them.
If one is using Go/C++/whatever WASM, why not go the extra step and use a binding framework for the OS's native UI toolkit, and just produce a native app? I don't understand with the fascination of bringing an entire OS (the browser) on top of an OS.
This is great but there many drawbacks.
I tried Qt but needed something native-er.
After much digging got to know about gioui[1] but it also has some issues.
Also Flutter[2] seems to be better fit but binding to golang is a little tough.
It's the difference between a new tab vs a new browser instance - every electron app is a new browser instance with fixed overhead of 100mb or so. A new browser tab is closer to 10mb overhead.
This is cool, didn’t find this in my googling. Like with go-app (https://github.com/maxence-charriere/go-app) though, it is a front and backend framework that seems closely tied together. I would like to see a front-end GoLang framework that can be reused easily. Still awesome, will take a look later
But I don’t want to write JavaScript(!) and deal with all the complexities that comes with it like npm, webpack, typescript… Fortunately, I can just compile GoLang to WebAssembly (WASM)
Okay...
Large WASM binaries (especially from GoLang): these take a long time to send over the network increasing loading times. In a desktop app the binary isn’t transferred over the network, so less overhead.
I forgot that you don't have to download desktop apps, they just appear!
Browser incompatibility: Some WebAssembly methods are unavailable in browsers and older browsers are not supported at all. In a desktop app the “browser” is controlled (Chrome for Lorca and Safari for webview), so no compatibility issues.
Electron???
This just seems like you built a less easy to use bundling/development platform than js/webpack/etc and claimed it was better when I'd argue it's way less mainstream and thus less accessible. Not to mention you could've just used native ui like others are talking about. Seems like the worst of both worlds to me.
"Hands-On GUI Application Development in Go: Build responsive, cross-platform, graphical applications with the Go programming language"
https://www.amazon.de/-/en/Andrew-Williams-ebook/dp/B07GYLYS...