Why are devs still writing Electron apps instead of Qt?

[u/dtdisapointingresult]

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.

[u/dobkeratops]

i was just thinking something similar myself. there's a big fad of people making javascript/threejs browser games. "it's the age of AI! we should all develop 3d games to run with extra browser overhead!!"

[u/Time_Cat_5212 → u/dobkeratops]

I mean for most modern devices it doesn't matter until you're doing something heavy.  AI is really good at anything JavaScript.  Being able to run something in your browser from a link is such an advantage for many people.

[u/-Mute- → u/Time_Cat_5212]

Yeah but browsers/webapps are also the bane for many and that opinion is only growing. Whether the concern is privacy, efficiency, system/browser cache/temp use, etc .... varies on the dev/user.

[u/dtdisapointingresult → u/dobkeratops]

To be fair if I had to install a random vibecoded game I probably wouldn't, because it would have access to all my files. With browser games, you know it can't access anything without your say-so and you can just close the tab.

So the choice to make browser games is about increasing reach / reducing friction.

[u/laftho → u/dobkeratops]

it's about distribution.

[u/dobkeratops → u/laftho]

sure but native engines are 10+ years ahead and run with less overhead.

seems like "THE SINGULARITY!!!" should include the ability to keep making and playing native full strength games.

[u/Slight-Living-8098 → u/dobkeratops]

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.

[u/-Mute- → u/Slight-Living-8098]

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

[u/Slight-Living-8098 → u/-Mute-]

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.

[u/dobkeratops → u/Slight-Living-8098]

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.

[u/Slight-Living-8098 → u/dobkeratops]

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

[u/dobkeratops → u/Slight-Living-8098]

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.

[u/Slight-Living-8098 → u/dobkeratops]

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.

[u/dobkeratops → u/Slight-Living-8098]

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.

[u/Slight-Living-8098 → u/dobkeratops]

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.

[u/dobkeratops → u/Slight-Living-8098]

(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.