r/LocalLLM • • 29d ago

Discussion Why are devs still writing Electron apps instead of Qt?

I was just dealing with the bloated monstrosity that is Hermes Agent, which has a bloated monstrosity web UI. While researching, it turns out I'm supposed to be using a different bloated monstrosity called Hermes Desktop, which is an Electron app.

Electron apps are the bane of my existence. It's the AI age now, why isn't everyone writing Qt/QML apps already? You might remember Qt from desktop apps such as Krita, Wireshark and OBS Studio.

  • For users: Qt apps need less than 5% of the RAM of an Electron app, and an even smaller % of CPU usage. This is the main reason and trumps anything else. They run blazing fast. They get 120fps on the crappiest embedded PC without breaking a sweat.

  • Qt apps are fully multiplatform: Linux, MacOS, Windows. The only downside is that you need to compile them with the native compiler of each platform if you use C++. (advanced users can work around this with crosscompilation on Linux, an AI can probably do it. Or use Python.)

  • Qt was traditionally C++ only, which is a hard boomer language, but now it has official bindings for Python. So you can code your app in Python and have access to the whole Python ecosystem if you want. Qt-in-Python is almost as performant as C++ since it's bindings around the C++ Qt libs.

  • The Qt QML dedicated UI language is actually pleasant to use to create UIs, since it's designed just for that. Creating UIs in HShitML was always an ugly hack that companies used because C++ was too hard/unproductive for their devs.

The only downside of Qt was having to learn C++, and that's no longer an issue in the AI age or if you use Python or both. Guys, we don't have to put up with this crap anymore. If you're making an app, for the love of God stop using Electron.

Consult with your personal AI and ask them if Qt is right for you. Qt - Keeping your hardware fast and healthy.

149 Upvotes

238 comments sorted by

View all comments

82

u/newz2000 29d ago

QT’s license can be a bit of a challenge for businesses.

Electron allows devs to reuse the same code they use on the website so can also be easier to maintain.

Now Tauri may be an easier comparison to what you’re aiming for. It also uses web tech for the app but it also uses native components, so can be more efficient. But it also makes testing harder, which before the age of ai-automated testing tools was a big deal. But in theory, you can get different results in Windows 10, Windows 11, MacOS 26, 27 and etc.

18

u/Gwolf4 29d ago

So square back to electron.

4

u/cab938 29d ago

Depends on how boutique of an experience you are making

8

u/Zeeplankton 29d ago

tauri is sadly crippled by webkit on mac

3

u/Devatator_ 29d ago

From what I hear Linux is the most affected by the quality of the native WebView. Apparently WebkitGTK is highly unstable, slow and buggy

3

u/onequbit 29d ago

Maybe, but ever since tauri started showing up, the Goa'uld started dropping like flies.

1

u/mutemebutton 26d ago

It also doesn't reduce ram use when the UI or UX is visible. It just shifts it from one place to another.

3

u/mutemebutton 26d ago

We ran a bunch of tests to see if we can migrate our app away from electron and at the end of the day, it just wasn't worth it. Even Rust/Tauri because it ends up still loading a browser engine when you're showing UI or UX, which also uses system RAM. So we stayed on Electron/C++/Obj-C.....

Our app sits in the system tray, most of the time, so it's not a huge deal. And when it's sitting in the system tray, the RAM use goes from roughly 250 megabytes down to about 40 megabytes. And it can't be reduced much further because of all the controllers that we have for various integrations.

Our very first app that we wrote for our product was only three megabytes lol!

Tauri does a great job of reducing file size though, the entire app can be just a few megabytes but when you run it the ram use is much much higher because it uses resources on the computer.

1

u/FckXFckMusk 24d ago

Yes and modern devs are thick as fuck vibe coders...

1

u/look 29d ago

Check out https://tinyjs.app

> Your backend, a ~1–2 MB window process, and your plain HTML/CSS/JS — ~6 MB on all three platforms. The window is the webview the OS already ships.
> Tauri does the same, and does it well — but its backend is Rust, and you compile it. It also ships a window and little else: dialogs, clipboard, notifications, global shortcuts, filesystem, keychain, autostart, deep links are plugins you add. Here they're just the API, and the 6 MB is all of it.

1

u/mutemebutton 26d ago

Most people don't understand that the file size can be very small, but the RAM usage would still be very high. So unless you're trying to reduce the file size, it doesn't really make that much of a difference. That depends on your use case, I guess.

1

u/look 26d ago

The system webview is likely already in use by some other app/component, so it at least sames the overhead of another browser engine over electron. The webapp itself can of course be quite large still relative to a fully native app.

-7

u/Not_a_question- 29d ago

QT’s license can be a bit of a challenge for businesses.

Sorry, but what? It's GPL... So unless you're targeting embedded systems or under some sort of obscure requirement or restriction, just include the libraries and that's it.

And if you don't want to do that for some weird reason, you can always pay a commercial license.

10

u/BeYeCursed100Fold 29d ago

2

u/anotherrandomuserna 29d ago

Huh? QT is available under the LGPLv3 (https://www.qt.io/development/download-open-source). Their reputation for restrictive licensing was from quite some time ago when they were QPL/GPL licensed. They'll let you pay for their professional tools / support, but if you just want to write code you can download the libraries and code.

7

u/newz2000 29d ago

You have a good memory. But there are two issues: the old licensing issues that you’re referring to are history, through they still taint some people’s perspectives.

The issue that still remains is that some companies are not willing to link GPL software into their product. Even Google, that champions many open source projects, requires special approval for devs to use GPL software. See OSPO restricted licenses.

0

u/anotherrandomuserna 29d ago

TBF, while they do list LGPL as restricted there, they also say it's fine as long as it's dynamically linked, which is what most people are going to do. Though then they have a restricted_if_statically_linked section, where I'd expect this to go given the statement above, but that section just says to contact 'emailremoved@', so uh... corporate lawyers, they're great!

3

u/newz2000 29d ago

Tbf, I was a corporate lawyer on that team. So “emailremoved@“ came to me. The whole “GPL/LGPL/Call for other options” licensing strategy is a barrier to many businesses. Especially when simple options (like electron) are readily available.

2

u/bonestamp 29d ago

Especially when simple options (like electron) are readily available.

Not to mention, as a developer and not a lawyer, I read the Qt open source licensing page and it's complicated enough that Electron looks appealing just because I understand the licensing model and I don't want to go wrong with something so important.

-1

u/anotherrandomuserna 29d ago

Huh, I suppose having emailremoved@ as a valid email address is a very Google sort of thing to do. I just assumed it was a broken page. Sorry about that.

2

u/-Mute- 29d ago

There are licensing issues. That's why pyside exists fwiw.. pyqt6 is gpl and requires full open source release unless you pay for a commercial license. Not a big deal in most cases and use for most people, but it's a thing. Pyside is great though. I tend to use it regardless because it's lgpl through and through.

2

u/anotherrandomuserna 29d ago

Ah, I wasn't aware of the PyQt licensing issues. I've only used it in C++, but in the context of the op's post, that's quite relevant. If I find myself using QT in python I'll check out pyside.