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