Picking technologies for a desktop app in 2016

Written by Michael

Update, December 2017: The gist of this post is that I considered Electron and PyQt. I chose PyQt for its superior performance. Eighteen months and ~2000 development hours later, I'm happy with this choice. I created an open source library with the solutions I've had to come up with. It can save you months of development work!

When developing a new desktop application, the most important choices from a technological point of view are which programming language(s) and GUI framework to use. fman's combination needs to tick the following boxes:

Cross-platform (Windows, Mac, Linux)
Good performance
Support for custom styles
Simple for users to extend via plugins
Fast development

What's interesting is that the choices of programming language and GUI toolkit influence each other. For instance, if you pick Electron as the GUI toolkit (/platform) then you must use JavaScript.

Speaking of Electron, it's a very exciting field at the moment. For those of you who don't know it, it's a platform for developing desktop applications that use Chrome's rendering engine for their GUI. Electron-based apps basically launch a (trimmed-down) version of Chrome on start-up, and then use JavaScript/Node.js to do everything you couldn't normally do with a browser, like accessing files or other system resources. Their GUIs are writen in HTML / CSS, just as on a web page, with lots of JavaScript.

Electron is the foundation for Github's Atom text editor, and Microsoft's alternative Visual Studio Code. Both of these tools have gorgeous GUIs. The fact that Electron apps are based on web technologies which are very widely known among developers has huge advantages for their extensibility (or "hackability" as Github calls it). A good indicator of this is that Atom already has about the same number of plugins written for it by users as Sublime Text, even though it has only been around for 2 and not 9 years. (Granted, Github's community also plays a large role in this, but it's impressive nevertheless.)

The weak point of Electron is performance, in particular startup time. Electron apps essentially launch a browser on start-up. On my late 2014 machine, this takes more than a second. On my older machine from 2010, it's close to five(!) seconds. There are attempts by the Electron community to solve this, but none that would seem to bring startup time significantly below one second. A workaround would be to always leave fman running in the background, but enough applications already do this and fman has no right to hog your system's resources this way. So, while it would be great to be able to use Electron for all its advantages, fman's focus on speed does not allow it.

At the other end of the performance spectrum is writing a custom GUI toolkit in C/C++. This is the approach taken by Sublime Text. Its performance is amazing and one of the main reasons why many people haven't switched to Atom. A drawback of this approach is that developing in C/C++ takes a lot more time than in higher-level languages. And creating a new GUI toolkit is also not something to be taken on lightly, especially when you think of all the things you have to deal with (blinking carets, scrollbars, font rendering, ...).

So, it makes sense to use an existing GUI framework. fman's emphasis on a beautiful UI requires a lot of custom styles, which rules out native widgets and libraries like wx. The most prominent framework that remains is Qt, and this is what fman uses. Some people have warned that Qt apps typically don't feel truly native. But, it is possible to customize the look and feel far enough to overcome this and make the fact that it's not fully native transparent to the user.

In the short time since fman's development started, basing it on Qt has already yielded enormous benefits. The current state of fman is a prototype that looks as in the screenshot on the home page. It launches instantly even on my old machine and can be used to navigate, copy and move files and directories. Imagine how far you would have gotten in a month developing your own GUI framework in C++! I think I would still be stuck on the build system ;-)

This leaves us to pick a language. The official Qt bindings are written in C++. Unfortunately, C++ is a horribly unproductive language (at least for me). A popular alternative in recent years is Go. Go is "only" two to four times slower than C, but easier to use and offers perks like a very small memory footprint or the fact that it compiles to single, self-contained executables. A drawback of Go is that it could not (easily) be used for fman's plugin API since it is not an interpreted language (so plugin developers would have to recompile their code after each change). What's also a disadvantage of Go when it comes to managing files is that its Unicode support is apparently not very user-friendly. All in all, It appears that Go is (currently) better suited for server-side apps where performance and memory footprint are critical.

Enter Python. After 15 years of programming, Python is by far the most productive language I have encountered. The standard libraries are awesome. So many people use it that you can just Google for a problem and usually find a ready-made solution. A good example of this are the Qt bindings (PyQt), which were developed by a third party. Python is also interpreted, so when you develop a plugin for fman, you can simply change your code and see the effects immediately. Its Unicode support (as of version 3) is great which means that you don't have to worry about bits, bytes or encodings. Finally, Python is extremely easy to learn. Even if you haven't used it before you will be able to pick it up immediately. It has made me a much more productive programmer and I am confident it can do the same for you.

No choice is without trade-offs and so also Python has its drawbacks. The main one is that it is extremely slow in comparison with eg. C/C++. fman manages this by only using Python for the "business logic" / plugins and performing computationally expensive tasks such as rendering through Qt / C++. Still, the amount of time spent by fman in Python code is something to keep a close eye on.

When Apple launched the App Store, a friend of mine from college made £50,000 (the equivalent of $100,000 at the time) writing apps over the summer. fman will have a package manager for installing plugins and may also allow you to charge for the plugins you develop. Some people have said that they would prefer a compiled language in this case, since Python's interpreted nature would essentially give everyone who has a plugin access to its source code.

While it is true that it is possible to reconstruct the source code from a Python application with near 100% accuracy, it also needs to be said that compilation is not obfuscation. For example, most Java programs can be decompiled with near-perfect accuracy. The solution in both cases is to use an obfuscator. For Python, there is a good obfuscator by Bitboost, which produces code that is virtually impossible to deconstruct.

In summary, fman uses Python and Qt via the bindings provided by PyQt. To see what it looks like, click the button below.

See fman in action

In the next post, you can read about some of the business strategy behind fman.

Appendix: Rejected GUI frameworks

This post picks Qt because it is "the most prominent" GUI framework fulfilling fman's requirements. Some readers have asked why it was chosen over other alternatives. The striking argument remains that Qt is what most people seem to use, which has a lot of advantages eg. when it comes to documentation on the net or language bindings. If you need to pick a GUI framework, you may be interested in the following list of alternatives, and why none of them was picked over Qt:

JavaFX / Swing: Can only be run in a Java virtual machine, which takes too long to start up.
GTK+: Seems to be the second-most popular alternative to Qt. Supposedly it works best on Linux. Since most of fman's users are on Windows / OS X however, this would not be an advantage.
wxWidgets: Very limited support for custom styles.
Tk: Old and stable with support for custom styles, but much less popular than Qt.
Windows Forms: Not cross-platform.