HACKER Q&A
📣 skwee357

I want to develop desktop application. Tauri or Qt?


I'm in the process of designing a desktop application, and I can't settle on a GUI library.

I plan to do the logic/core in Rust, and have been evaluating different GUI libraries, and eventually settled on two: Tauri and QT.

Tauri uses the system webview, so it does not bundle chromium like Electron does, but it's not native per-se. It's still web technology.

QT, through qmetaobject-rs, allows me to write minimal C++ and use QML. While QT is not native as well, it looks, and behaves more natively than web app. I figured out that I can link QT dynamically, and as long as I use LGPL module only, I can keep my source closed. The moment I will be able to sell the app, I'll be able to afford QT's startup license (AFAIK $499 per year) if needed.

I have an initial mock with Tauri, and overall I like it. However, I feel like with QT I might be able to move faster due to QT Creator and visual design tools, as well as having predefined theme/style for the components.

What do you think?


  👤 rubymamis Accepted Answer ✓
Although I've used Tauri only minimally, I have a lot of experience developing in Qt C++ and QML. I can say that QML is such a wonderful language for GUI development. It's just so obvious that GUI development should have been this way all along. I'm developing a block editor (Notion style)[1] and it's been great so far. One thing to consider is how well does Rust integrate with QML. I'm using a lot of C++ code that connects directly to QML code (via invokale functions, signal/slots, and Q_PROPERTYs, etc). So I would research more into that if I was you. The benefit of having the backend (aka, logic) in a compiled language is great for performance. Also most Qt Quick components and most QML code is compiled to C++[2] nowadays.

Yes, there is a lot to be desired in terms of built-in components that look native but there a 3 ways to look at it:

1. Qt is improving there. For example, Qt Quick now provides native dialogs and file pickers on most operating systems[3] (currently native dialog support is lacking on Windows if I remember right).

2. It's very easy to customize the look and feel of components to achieve the look that you want.

3. Many open source projects are available to take your Qt's project to the next level and make it feel more native. For example - qwindowkit that allows you to create native frameless windows.[4]

I have to go now, but if you have any questions, feel free to ask.

[1] https://www.get-plume.com/

[2] https://doc.qt.io/qt-6/qtqml-qtquick-compiler-tech.html

[3] https://doc.qt.io/qt-6/qtlabsplatform-index.html

[4] https://github.com/stdware/qwindowkit


👤 ogoffart
As the author of both Slint and qmetaobject-rs, I wonder if you checked out Slint[1] and what were the reason you didn't pick it.

[1] https://slint.rs


👤 nabla9
> I figured out that I can link QT dynamically, and as long as I use LGPL module only, I can keep my source closed.

You can link statically LGPL libraries as long as you don't modify the code in the library and provide access to object files so that someone could do the linking manually. Not a difficult burden.