In this book, we explored seven popular GUI toolkits for the Go language. It's recommended to read each chapter and understand the benefits and potential drawbacks of each toolkit before making a decision on which to use in a project. For a quick reference, the following table should help to short-list options based on a number of important factors:
Name | License | MultiplePlatforms | Active | Themes | Nativewidgets | Idiomatic | Cross compiling | Richness |
Walk | BSD | ✔ | ✔ | ✘ | ✔ | ✔ | ✘ | ↑ |
andlabs UI | MIT | ✔ | ✔ | ✘ | ✔ | !1 | ✔ | - |
Go-GTK | LGPL2 | ✔ | ✔ | ✔ | !3 | ✘ | !4 | ↑ |
qt | LGPL | ✔ | ✔ | ✔ | !3 | ✘ | ✔5 | ↑ |
Shiny | BSD | ✔ | ✘ | !6 | ✘ | ✔ | ✔ | ↓ |
nk | MIT | ✔ | ✔ | !6 | ✘ | ✘ | ✔ | - |
Fyne | BSD | ✔ | ✔ | !6 | ✘ | ✔ | ✔ | ↓ |
1 The top, declarative, layer of the andlabs UI is designed for Go development; however, it exposes C idioms from the lower-level library.2 The go-GTK library is available in multiple licenses, but the inclusion of the GTK+ widgets requires LGPL.3 Using theming capabilities, a native-looking user interface can be obtained.4 Cross compiling should be possible, but it requires many libraries to be compiled for each target system.
5 The supported way to cross compile is through the use of containers rather than directly on the development computer.6 Themes can be set from code but there's no collection of user installable themes.
The preceding table should help with the choice of which GUI technology to use. There's no single best option and selection should be made based on your most important criteria. Clarification of each heading is as follows:
License: Every toolkit is available under an open source license that allows for open or closed source and commercial usage. However, as a statically compiled language, there are complications when using the LGPL. If statically linking with an LGPL project, your code should either be distributed under the same license or you'll need to provide an alternative compiled output without the library statically linked. The easiest option in this case may be to leave the toolkit as a dynamically compiled library that the user would have to install before your application can function. Some of the toolkits are available under a separate commercial license that can be paid for to avoid licensing complications.
Multiple Platforms: A tick mark represents the toolkit supporting at least Linux, macOS, and Windows. Some of the options provide support for many more platforms.
Active: Is the project actively maintained? An active project doesn't guarantee the availability of commercial support.
Themes: A tick mark represents user installable themes that can customize application appearance. Some toolkits support setting a theme using code that allows application developers to change the look and feel.
Native Widgets: Does the framework use native system widgets? A tick means that applications will utilize the system widgets. Some toolkits make it possible to look like the system widgets by installing a special theme.
Idiomatic: Is the toolkit built to fit with the Go language idioms? This may not be important to every project, but it can improve the speed of development and ease of maintenance. It can also be easier to debug applications that use an idiomatic toolkit.
Cross compiling: Cross compilation is usually important for Go applications. Not all toolkits support this completely due to the complexity of working with low level graphics libraries.
Richness: This is a measure of how complete the selection of widgets is. An up arrow indicates that you could build a complete application using the provided features. A bar (neither up nor down) shows that most applications should be possible but that it may be necessary to construct complex widgets using the available components. A down arrow shows a minimal widget set—simple or medium complexity applications are possible but many widgets would need to be built from the basic components provided.