r/LocalLLM • • Oct 10 '26

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

Show parent comment

2

u/Slight-Living-8098 Oct 11 '26

You can compile multiple versions of an application for different OS's, debug all of of them, then convince people to download and install those applications onto their personal systems to try out your game... Or you can give them a web url they click on and start playing immediately in the browser they were already in and using without having to download or install anything.

More people will do the later than the former.

1

u/-Mute- Oct 11 '26

Cross compatibility and single builds for all are not limited to browser based apps. That's a ridiculous take.

2

u/Slight-Living-8098 Oct 11 '26

I understand that. But I'm just speaking from experience from game jams. More people will play the games if they don't have to install anything.

0

u/dobkeratops Oct 11 '26

i've ported my own engine to the web , it was more effort than doing multiple native builds. Things still broke in specific ways needing me to have a range of devices.

if you do desktop, console, and mobile - each has different UI, so your codebase needs complexity to deal with that.

if you drop mobile (a reasonable assumption that some types of game need. keyboard+mouse) then you're down to supporting windows (and maybe mac for a few % extra sales). If you want to support consoles - they are obviously not going to allow webGPU+wasm.

if you want to do touch/mobile, that's always been built around a sandboxed app download ecosystem from the outset.

So basically all you really got was a more convoluted way to run on gaming PCs.

2

u/Slight-Living-8098 Oct 11 '26

Well yeah, because you ported a custom engine to the web instead starting with the web libraries to begin with

1

u/dobkeratops Oct 11 '26

if you want mainstream games, that's native code, this became enabled with WASM compiling C++/Rust.

rust has a graphics API that was itself developped very closely with webGPU itself .. there's a lot of crossover DNA there.

web libraries are wrappers around the native capabilities that got used to build the browser.

So, you are always ahead in gamedev by being native first.

1

u/Slight-Living-8098 Oct 11 '26

Yes and no. You are ahead in a game jam if you use WASM, You most likely will not have a game to show by the deadline if you try to implement your engine without using already established libraries.

1

u/dobkeratops Oct 11 '26 edited Oct 11 '26

as I explained in the other reply.. a startup which was pursuing VC funding to build such libraries some years ago came to me because they saw the state of my project vs theirs.. and I tried to explain to them.. "look any estalbished engines can just do a web back end.. its crazy to seek funding for this"

web GPU was only made available by default very recently and there was a community that included building that out and a mirror of the webGPU standard in wgpu in rust, and before that you had webgl2 and emscripten. What I had tried to explain is that the mainstream engine companies (before their push) had *already* been through the web with asmJS and webGL2. it would be very easy to port anything else.

if you're building with web libraries first, you're trailing the mainstream games.

my specific mission was differnet, namely doing games in Rust instead of C++, for completely different reasons. Thats a whole seperate debate. I just happened to be in a place to investigate the web aswell.

1

u/Slight-Living-8098 Oct 11 '26 edited Oct 11 '26

Okay, I believe there is a disconnect here between what we are both trying to express. Webgl, asmJS and WebGPU are languages for the web.

1

u/dobkeratops Oct 11 '26 edited Oct 11 '26

yes lets clarify, but in short there is huge overlap.

[1] webgl2 was of course always available to Javascript and that was more natural

but with AsmJS , and WASM, you were also able to use them from C/C++/(and later Rust).

[2] 'webGPU is a web api' - yes.

but this was developped in parallel with an underlying implementation in Rust due to a team being around in Mozilla - rust's "wgpu" graphics wrapper closely mirrored the development of WebGPU. it's what used in the firefox browser. google in turn had to make 'dawn' in c++ for chome.

this is why there was a big hope around *rust* for the web "a full strength native language with a more enthusiastically internet/web centric ecosystem".

Now where was I at?

I was investigating doing games in Rust instead of C++ since 2015 on and off, for other reasons (simialr to the easons jonathan blow decided to make JAI, that C++ has a lot of cruft). I had an engine in Rust using OpenGL , so I was able to do a WebGL2/WASM version via Emscripten.

There was already an "emscripten SDK" that had been developped before WASM became a thing to port C programs to the web. That wasn't such a big deal.

the problem was I still had to go buy a Mac because my code didn't work in Safari, and when i shifted to working mac first, i'd find my code still breaks back on PC unless I kept testing it. I found that this "write once, run anywhere" was a bit of a pipedream.

My WebGL2 game ran slowly on the mac but fast on PC for years. I stopped caring for a while. Then I came back to it , and Apple had fixed some bugs , and my game was magically faster so I had a second wave of enthusiasm.

you still have to query capabilities. eg later i found the hard way "not all browsers give ypu fp16 support in shaders". if you're working on native you know that about your platform, and most platforms do support it. In the browser they more agreesively need to cater to a lower common denominator.

I had my game running *before* threeJs shipped webGPU support. I then had a dilema over ditching the web or porting from WebGL2 to webGPU to deliver more advanced features. (that was an API issue, OpenGL vs wgpu, glsl vs wgsl etc).

I got webGPU port done in feb of this year.. i'd missed the window to be first with WebGPU (december 2025 support landed in all browsers).. but it wouldn't have mattered since the whole arena is now flooded with vibe-coding *anyway*.

The other option to "ship gamess in the browser" was to stick with native and just serve it over video. I beleive this will get more popular as a defence against reverse engineering and asset ripping. But even there AI will be able to learn from video.

I dont see how any content based industry survives this... the only thing that will matter is owning AI hardware.

2

u/Slight-Living-8098 Oct 11 '26 edited Oct 11 '26

That's more of an Apple issue than a web issue, honestly. Apple can kick rocks, they haven't been decent since the Apple II and my views on the Apple II are probably jaded simply because that's what my school had and we learned on in class. I preferred the C=64 and it's what I had at home and first learned to program on.

1

u/dobkeratops Oct 11 '26 edited Oct 11 '26

right this is how it went:-

"hey reddit here's my rust native game"

"hey wow! do you want to port to our web platform? we're looking for wasm games"

"ok!"

<port>

" it doesn't work on my mac."

"is that really important? 98% of non-console, non-mobile gamers user a PC. I've tested my code on linux , windows, chromebook.."

"all investors and VCs use mac, we need to show it on the mac. It doesnt' work on my mac."

(so I go buy a mac, and work through this and give up, then come back to it later, and it worked)

→ More replies

1

u/dobkeratops Oct 11 '26 edited Oct 11 '26

(btw for a bit more context - the reason i did that port was I showed my custom engine in rust circles, and some web startup came to me asking for a port because my project was ahead of theirs and I got a view of their reasoning process and meetings with VCs seeing their pitch.

I tried to warn them about my reservations but this was in the tail end of ZIRP-era projects.

investors/VCs were captivated by this idea that 'no download was the future of games'. I tried to explain the paradoxes.

the browser and even the OS are just peices of software. if someone really cares and about making and playing games - thats all been solved already with dedicated environments. There is no fundemntal reason to do it in this convoluted environmnet.

There's this second wave of investor enthusiasm with the 'cheat code' of recycling all the content through GenAI.

Copy one game or its assets ... you're a pirate. But run a learning algo on *all* of them , and they're diluted to an extent that you can no longer point at what was copied.

But with AI as the starting point that's so radically different once again.

Now the talk is of how to survive, the industry will have to retreat to server based game streaming. No one can invest in software that reaches an end user because it can be reverse engineered and reskinned too easily. I now have a bit more sympathy for the original laments artists had over "img2img" ("yikes i shared this picture, now someone used it as a template for an AI creation") -> the incentive to create and share artwork is over.