For years I assumed Qt being the first choice for user interface development in a C++ environment. It was used in a lot of embedded systems and looked like it would gain some traction in the mobile market as well. Open source applications were being ported over from GTK to Qt (e.g. Wireshark, subsurface,…). Large applications like Spotify and Autodesk Maya made use of it. So what’s wrong with Qt? Advancements in web technologies, licensing trouble, available engineers on the market and other factors have made alternatives attractive.

Qt is a good framework for User Interfaces …

Desktop applications have made use of Qt in the past because it provided a way to use native widgets and still create a cross platform solution. Qt Widgets did this reasonable well and famous open source applications like VLC still make use of this today. Alternatives like GTKmm have existed for ages but due to their custom widgets, the resulting applications always looked slightly out of place. Qt also had strong support in the open source community through the KDE project.

… but has it’s own set of issues.

With the introduction of touch based interfaces, gestures and animations have become more important. Nokia, who owned Qt at that time, had started working on QML (QtQuick) to make it easier to create such interfaces. I initially had one of their first releases running on a Symbian device. Later on the Qt Company which now owns Qt has released the second version of QML (QtQuick). These days it is possible to create well performing custom user interfaces on embedded systems as well as mobile platforms. So all good? Let’s have a look at the pricing and licensing of the framework. The cheapest option is targeted towards mobile app development and costs 3620 USD per year and developer as of the time of writing this blog post. Prices for embedded platforms aren’t listed and on a per device unit. Understandably it is expensive to maintain such a huge framework but for a lot of small business these costs are a dealbreaker. So is releasing the UI or the full application as open source and using the LGPL version of Qt an option?

Mobile Platforms

Of course releasing as open source has a major impact on the business model. But some projects have chosen this option. One particular piece of software I have in mind is makemkv. It has a proprietary library containing the main functionality of decoding certain kinds of optical discs and an open source user interface. So can this be an option for other projects as well? Unfortunately there are issues with this approach. Using LGPL licensed code in embedded systems firmware usually means one has to allow the user to exchange those parts on a device. But usually that is not intended and also poses challenges when the platform should use secure boot and a signed firmware. Also shipping applications on mobile platforms usually requires one to add the app into the app store of the respective platforms. Unfortunately installing an app on an iOS device requires a 99€/year developer program subscription, meaning it is not on option for many hobbyist projects. Additionally Apple seems to have caused trouble in the past with apps containing (L)GPL licensed code. Although the European Union has finally put the Digital Markets Act in place, it will take some time for Apple to come to their senses and make iOS a more open platform.

Alternatives

In the mean time we have to find a solution to create applications serving all kinds of use cases. One thing that comes in handy is the move towards cloud and micro service based architectures. Monolithic applications are a rare thing these days. Meaning APIs, created using GRPC or following the RESTful concept, are quite common. Fortunately using these APIs in web applications is quite common as well. Meaning creating a user interface based on web frameworks is a viable way for a lot of use cases. Need a decent framework to structure your UI code. Have a look at Vue.js or React. Need some 3d visualization? Check out three.js! All these frameworks can easily be managed using npm. Altogether those frameworks offer most of what’s needed to build frontends for most use cases.

Yet another Pet Project?

So while I worked on a larger project including React recently, I also had to rewrite a personal project yet again. A few years ago I built a custom home automation solution for my parents house. Of course that means I’ve been maintaining it ever since. I already rewrote it once a few years ago and wrote about it in a blog post. Unfortunately iOS devices have found their way into the household and the Qml based application couldn’t easily be run on the new iPhone and iPad. Well at least not without paying for the apple developer program and in the worst case Qt as well.

This left me with two options. Either rebuild everything and find a way to include the existing hardware into Home Assitant or build a new web based frontend. I chose the latter as writing a very basic UI in React only took a few hours.

I initially planned on just generating the client code for the grpc service. Unfortunately I seem to have been doing something wrong as the grpc library failed with some error messages about missing components. It looked like it would only work when targeting the node.js environment rather than a browser. (Recommendations on how this can be solved are welcome!). Fortunately I’ve been toying around with boost::beast recently and had some code around. I used this to implement a few RESTful service functions and patched them into the application running on the Raspberry Pi. From there I only had to implement the client code in TypeScript using the fetch api. A relatively short amount of time later I had this web application ready:

The new application shown on a Xiaomi Pad 5 and an iPhone 13 Pro Max.

It of course won’t win any design awards but it most certainly doesn’t have to. It will run on any future devices my family members will likely own thanks to web technology.

Conclusion

A lot of projects I’ve worked on in the past could have been implemented with web technologies as well. This experience with the hobbiest project and some other projects as well therefore isn’t surprising. While I would still argue to use other languages like C++, C# or Rust for work on the backend, creating frontends with web technology is a great option.