That is a crazy amount of resource hogging at 3GB.
You're running a music player, a text editor (or IDE), and a chat client. I would expect reasonably that would use less memory. One point you could make is that even native application alternatives, ones that don't use Electron, would be bloated and I would have to agree. Visual Studio .NET is pretty darn slow/cumbersome itself.
Back in 1999 I was running Emacs, xchat and freeamp on my Pentium 66 with 16Mb of RAM. (an weak machine, even for 1999 but with Linux Mandrake and WindowMaker it was usable)
The UI was less sophisticated and it doesn't involve network connection but sometimes I'm wondering how did we get there...
A lot of this comes back to higher expectations: we now have much larger displays, color depths, instead of simple bitmap fonts we have much higher-quality rendered vectors with advanced layout systems which can complex scripts, etc. Instead of rendering into a shared buffer, each window has at least one (on OS X, two) full buffers and the whole thing is composited, which is great for responsiveness and visual quality but definitely uses In the 90s, 640x480 was a common display resolution — now Apple recommends that developers ship 512x512 icons.
That's not to say that there aren't decisions to reconsider about code size, resource formats, etc. but I think it's easy to forget how much more behaviour has moved into our default baseline assumptions.
In my very limited experience, this makes programming anything several times more complicated. Writing a document editor? Difficult. Writing a networked, multi-user document editor? As difficult as the last thing but with asynchrony and lots of new failure modes.
You're running a music player, a text editor (or IDE), and a chat client. I would expect reasonably that would use less memory. One point you could make is that even native application alternatives, ones that don't use Electron, would be bloated and I would have to agree. Visual Studio .NET is pretty darn slow/cumbersome itself.