Writing GUI apps doesn't have to be painful

Recently, I came across the article Writing GUI apps for Windows is painful which resonated with me. Just over a year ago, I was in a similar position as the author. I was just starting a new project and was looking for a GUI library with the following requirements:

• Should support Linux
• Should be easy to set up for development
• The compiled binary should be small and easy for the end user to use (minimal dependencies)

The project I was starting was a reader for smart card documents (like personal identification cards). As the project was new, and the GUI would be an important part of it, I decided to remain open to solutions in different languages. Therefore, I was looking for a language and UI library combination that would give me an environment in which I could easily develop the new application (note that my new application doesn’t have big requirements from the UI library: labels, images, message boxes, and buttons are enough). Also, I wanted an environment that would be easy for others to set up. I didn’t want to lose contributors just because my library required dozens of obscure dev packages, black magic, and hours of configuration and compilation (cough, Qt, cough). These were the alternatives I explored at the time:

• C/C++ - there are a lot of C/C++ GUI libraries available, for everyone’s taste. Even if you look only at actively developed ones, there is a choice of a dozen nice libraries that would work for me. But, as I had experience writing C, I knew how painful and slow development could be in these languages. Neither C nor C++ has some kind of package manager, which stops me from quickly trying libraries (not just UI ones, I also needed PDF, HTTP, and cryptography libraries), and stops other contributors from quickly starting to work on the project.
• Electron - developing the UI would be really easy (and fun), trying out new libraries would be easy, and everyone would be able to contribute. However, I didn’t like the idea of distributing 400MB for a simple app such as mine (a similar app developed by the State of Serbia takes under 7MB). This would have been my fallback option..
• Rust - I liked the idea of writing the project in Rust (I even developed an initial, console-based version in Rust), but the state of the ecosystem turned me from pursuing the idea. The community didn’t have a definite answer on which library should be used for GUI, and even the most developed libraries didn’t promise elegant UI development.
• C# - I didn’t think much about this one at the time. Reflecting back, it would probably be the perfect choice if I was developing for Windows. But not for Linux.
• Haskell - I had prior experience writing a GTK application in Haskell. That process isn’t perfect, but the productivity boost you get from Haskell as a language makes up for everything else. However, this choice would reduce my contributors by a factor of 10x (at least).
• Go - at the time I had a love-hate relationship with Go from my previous work. A lot of things annoyed me about Go (most of them still do). However, the more I delved into it, the more it seemed like the ideal choice: Go can be understood by everyone, it is embarrassingly easy to install and compile programs with it, and it has a lot of stable libraries including Gio and Fyne for GUI. Neither library is the pinnacle of UI design, but both were more than adequate for my needs.

In the end, I took the plunge and chose Fyne. Now, one year later, with hundreds of users and dozens of contributors (half of them via mail), I can only say that it was the perfect choice. It did everything I wanted (even more), and everything I did with it was easy (compare this with requests from the cited article):

• Support for Linux, Windows, and macOS;
• Zero dependencies for end users. It just works for everyone;
• 5-minute setup process for developers;
• 10-minute workflow that tests code and releases binaries for Linux and Windows (no cache used);
• Easy theming with support for dark mode;
• Relatively small binary. Not as small as what you would get with C/C++, but still under 30MB;
• GUI code is straightforward (actually, all code is straightforward);
• Commercial usage allowed (not that I needed this)

Of course, Fyne isn’t perfect. Styling abilities are far from what you get with libraries like GTK or Qt - With Fyne, you are locked into flat aesthetics. The documentation could also use improvement ¹. Ironically, I think that the design of the documentation website is the worst part of it.

Will Go+Fyne cover your needs for your next GUI application? I don’t know. But I know that there are projects for which this is the perfect choice. Dare yourself to start with simple tools. You will be impressed by how long they will take you.