Hacker News Reader

Comment by mrwoggle | Hacker News Reader

I just made hello world window in qt. It's 28 kB. edit: typo

28kb? You're only seeing the tip of the iceberg. I just built Qt Hello World myself. It's about sixty megabytes in size.

    jart@debian:~/scratch/qtproject$ qmake -project
    jart@debian:~/scratch/qtproject$ make
    jart@debian:~/scratch/qtproject$ ldd ./qtproject | grep -Po '(?<==> )[^ ]*' | xargs ls -alH | awk '{x += $5} END {print x / (1024 * 1024.)}'
    59.5916

That's bigger than I expected to be honest.

Aren't you also listing all the non Qt libs here ? X11, libinput, pulse audio, dbus, gstreamer, OpenSSL... e.g. here on linux for a static build of Qt (which links against both X11 and wayland platform plug-ins, and uses an embedded libpng, harfbuzz, freetype, etc...) a QWidget hello world comes out at 14 megabytes.

Id say its fair game if building hello world links those gstreamer and openssl.

> Id say its fair game if building hello world links those gstreamer and openssl.

why ? it entirely depends on how your linux distro chose to build Qt, not on Qt itself.

Because application can't run without those libraries. It's like comparing Java application without taking JVM into account.

> It's like comparing Java application without taking JVM into account.

no, it's not. The "equivalent" of the JVM would be the libQt5{Core,Gui,Widgets...}.so ; but here we are talking about the operating-system-provided libraries, so it is like comparing with a Java application, with the JVM, and also for instance all the MS Windows system libraries, or all the macOS frameworks like CoreFoundation, etc etc.

OK, so in this context the app is X MB. If all distros link those libs with libre cote and ui, for all intents and purposes, it takes X MB. If some dont, then lets discuss it (but if you can link to gstreamer and openssl to build a hello world, the issue is not entirely on the distro shoulders)

The thing is nobody actually uses hello world programs, by the time you build a real application the difference in RAM usage between that and a good Electron app for example blurs significantly.

I disagree. I remember using lots of GUI apps within a 96MB budget 25 years ago -- even browsers.

Electron does not provide that much more desired features than apps from 25 years ago.

You can make a very decent Electron app with roughly (roughly = ~2x or less) that amount of RAM too if written well, for that you get pretty much a codebase that you can use everywhere, which on it's own is _massive_.

I've noticed Signal Desktop only uses 100mb. That is quite good for an electron app. A simple server-side node process will use at minimum ~20mb, which obviously does not include a browser.

It's open source, I've been meaning to poke around and see what they are doing differently.

There's no secret really, just don't import junk dependencies like most people do and spend some time inspecting your memory usage every now and then, with very little effort you'll probably cut down on your memory usage significantly by doing that. With a lot more effort often you can probably even make something faster than uses less memory than a supposedly native app (if they spent less time than you optimizing it).

Signal desktop runs as multiple processes. Did you add up all their memory consumption? On my Debian laptop, Signal processes consume about 700 MB of RSS in total, immediately after starting.

> Electron does not provide that much more desired features than apps from 25 years ago.

That's true, but advanced GUI features aren't Electron's selling point. It's used because it offers easy portability and the ability to leverage web-dev skills.

What does Electron offer in terms of portability that SDL2 doesn't have?

The larger point is ease of use

Fine, "What does Electron offer in terms of easy portability that SDL2 doesn't have?"

Accessibility would be my immediate thought, although I'm not massively experienced in terms of GUI programming, so I could be off the mark here.

With something like SDL2, I would have to interface with each operating system's accessibility API directly, in such a way that's not easily portable, unless I bring in a separate library. Even something like GTK has this problem on platforms other than Linux. With Electron, I know that my program will be accessible wherever Chromium's rendering of HTML is accessible, which is a lot more places than anything I'm going to be able to bodge together.

SDL is intended for gaming and similar applications, it isn't intended for general purpose GUI development. That's what toolkits like Qt and GTK are for. These toolkits do compete with Electron.

With the disclaimer that I don't know a lot about this: Electron has solid support for both desktop and mobile targets. I don't think Qt's mobile support is as good, but I might be mistaken.

Looking at a few things on my machine right now:

- Emacs (with 251 open files and IRC running): 100MB

- Activity Monitor: 98MB

- Word: 227MB

- Spotify: 465MB

- Slack: 526MB

- Thunderbird (not Electron, but a similar weird browser hybrid thing): 663MB

- Teams (which appears to be Electron): 747MB

I'm not seeing too much of a blur here. The worst chat app (Teams) is using ~7x the RAM of my primary code editor that also is doing chat :).

What some people actually build with Electron doesn't really say much about what people _can_ build with Electron.

You can't just compare Emacs with Spotify here, I can't even scroll a list in Spotify without seeing it disappearing on me momentarily, that says more about Spotify's engineers or project managers than it says about Electron.

Teams and Slack kind of address the same problem and I'm seeing wildly varying numbers reported by you, without knowing anything about how you are using those apps those numbers are meaningless in my opinion, and if you think they are meaningful then clearly you can achieve different results despite addressing the same use case with the same technology stack.

Also there's "chat" and "chat", there's a reason ~nobody uses IRC anymore compared to Slack, they are not the same thing, and it's not just that Slack is easier to use.

> What some people actually build with Electron doesn't really say much about what people _can_ build with Electron.

no, it does. anyone can build incredible apps on any tech, given infinite budget and time. What matters is how the average app behaves, and for electron it is much worse than the average Qt app for instance.

That argument makes no sense to me, do you think you'd change your mind on Electron if access to it were restricted only to very intelligent and motivated people who made very good apps then?

The average Qt app would probably be close to the average Electron app if Qt attracted the same kinds of people, i.e. Electron is basically just easier to use and/or the developers picking it think they are getting more value out of it.

> That argument makes no sense to me, do you think you'd change your mind on Electron if access to it were restricted only to very intelligent and motivated people who made very good apps then?

but that's not the world we live in - everything has to be considered in that context and not in the abstract, in order to make any sense. Consider musical instruments - you can technically make great music with literally anything. But if, say, 80% of what people are doing with a given instrument ends up sucking, the problem lies more in the instrument than in the people, even if a very talented (and dedicated) 20% is able to make symphonies with it.

I’ll flip this around. Can you think of any Electron apps that aren’t hugely bloated as examples of Electron-done-right?

I think vscode is pretty good.

Just opened it up and it's... ok. Have 4 files open (all from the same project):

- VSCode itself 453MB

- cpptools (language server under the hood) 573MB

In the mean-time, I've been doing most of my work all day in Emacs and it has bloated up to 126MB :).

Edit: I will admit that the cpptools stuff is very nice. I do most of my C++ work in Emacs, but when I'm dealing with weird template type stuff I'll switch over to VSCode for the nice affordances it offers.

Edit 2: Just tried using VS Code to debug something that I can't quite grok.

    IntelliSense process crash detected.
    IntelliSense process crash detected.
    IntelliSense process crash detected.

Ahhh well, I can't really blame it on this one :D

I can't speak about the LSP, other than that that sounds about right to me, maybe you have a lot of free ram or some extensions installed? I would expect the memory usage to be lower than that otherwise.

You can't really compare Emacs with VSCode here, among other things you can basically get vscode to run in the browser without many problems etc. It's like saying that one can edit text with nano which is 150kb, sure but that's only part of what vscode provides you.

Heh the embarrassing thing for Teams in this case is that I’m signed into one team that doesn’t really use it for anything but conference calls, while I’m also signed into 8 or 9 heavily used Slack groups.

NodeGui (which is used here) is also running on Qt.

Reply on news.ycombinator.com