We seemed to get by with MSN Messenger with far less RAM, and the features were pretty much identical.
It boggles the mind how memory-intensive some of the modern apps are. It's insane.
That large companies also do this is another story entirely.
The GUI used wxWidgets using C++ and included a 3D section for system layout (using OpenGL). All of the 2D GUI controls for the rest of the system were "owner-drawn" which means that they overrode the ::OnPaint and drew themselves so as to look different than native controls (as audio systems always have to "look different").
This means buttons, toggle buttons, radio controls, control surfaces, sliders, meters, compressor meters, knobs, graphs, charts, lists, grids, EQ control graphs, everything. There were no native controls other than in popup dialogs (like saving/exporting). It redraw every 50ms based on data that it was receiving over the network from a series of hardware, with this data logged and processed in background threads. It used less than 1% CPU and a fraction of the RAM mentioned here for a chat app, even with cached in-memory bitmaps that it generated in code for drawing.
This ran on Mac OS, Windows and Linux. This means a native binary on each system. It can be done.
It is wrong to say that this embedded-web-app way is the "only way" of doing it. Not to be rude, but it just means that the devs can't be bothered to do it another way.
And that was me writing all of it, plus one guy who did the networking library. Two of us.
How can they "not have the resources"?
Web dev tends to optimize for ability to change/improve quickly (for good and bad). Resource use on the computer typically not prioritized.
I feel Signal should have implemted the core messaging components as a non-gui program or library or plugin to another Messaging app (e.g. Pidgin). Then if they want their own app, they could have used a lightweight cross platform window toolkit (e.g. WxWidgets or Qt).
I've got a lot of tabs open right now and I'm not sure how to read the memory usage in Chrome's task manager, but Chrome appears to claim to be using about 450MB just for the browser, plus some additional amount for each tab I have open.
Last time I've had it installed it was something close to a gig. But then it became a cluttered monster I rather fear so that's not relevant anymore.
Same goes for this. I'm happy to give that RAM to Signal since what I get for it, is more then worth it and I have the RAM left. It took me more time and headaches to get people to use Signal on their phones in the first place than it will ever for that 130MB RAM.
If efficient use of something like RAM is blatantly disregarded, what about more important things like performance-critical sections of code? Would you be happy that it is shoddily written?
The same approach on a mobile device would be widely condemned due to the hogging of RAM. I don't see why the same metrics cannot be applied to desktop software.
Is the solution for badly-written slow software "just get a faster CPU"?
I would like if it could use less resources, minimize to tray, etc. etc. etc. but for the moment, this is good and the RAM usage is a far less dramatic issue to me than it seems to be to many here.
I mean, there is far worse out there. I sometimes play Elite Dangerous on my other Win machine. There is a community build tool to track your flight route from the games logs (EDDiscovery) and it delivers an endless amount of features. It rests on a pretty huge database. This thing eats up my ram like it's some free gigabyte cake. I even have to launch the game first or it would take forever. It's horrible. The tool is great though and I will have it running when I need it and it does not hurt my remaining experience. I would love if it could use less resources but I won't stop using it because of it.
Everything about skype indicates that it's badly written. This is a text messenger that can't handle copy and paste operations correctly.
-- Niklaus Wirth
a. A smaller executable that makes efficient use of your machine's resources
b. A developer with less knowledge and experience who is able to write a memory-hogging desktop application
Whether you consider JavaScript a sane language is up to you. :)
Electron is several things which HN guidelines probably won't allow me to describe here. I avoid it whenever I can.
