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