Back to Index
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. Zillion people corrected me, saying that both languages have package managers and that I am C noob. I made mistake when I wrote above sentence, and I am C noob. Still I don’t withdraw my conclusion: using 3rd party libraries in these language is significantly harder than in languages I will list here. - 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 worked with it, the more it seemed like the ideal choice: Go can be understood by everyone, it is unbelievably 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.