6 ms·
Not a single of those happened to me. Are you sure there is nothing wrong with your PC? It uses 130MB RAM here (Win). How much is it on your side?
by aluhut 9y ago
Not a single of those happened to me. Are you sure there is nothing wrong with your PC?
It uses 130MB RAM here (Win). How much is it on your side?
- mrmondo 9y agoHowdy, glad to hear it’s less for you, that’s a much more reasonable amount of memory to use but are you sure you’re including all active memory from each of its processes / worker threads?
- 72deluxe 9y agoCall me old, but how can a messaging app like this use 130MB RAM? I am exasperated that Skype on my machine is using 109MB with only one conversation window open. 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.
- pjmlp 9y ago"Software is getting slower more rapidly than hardware becomes faster." -- Niklaus Wirth
- wh313 9y agoIt's because Electron has taken over desktop app development. While it does significantly lower the knowledge barrier to building desktop applications, it does come with a heavy memory overhead.
- StavrosK 9y agoHonest question: What's an easy-to-use, popular cross-platform framework with bindings to a sane language? Something like QT/GTK to Python? I hate Electron, but what's the alternative? I used wxWindows back in the day, with Boa Constrictor, and I loved that workflow.
- Multicomp 9y agoSo I don't know about the definition for popular or sane languages but FWIW Lazarus is a free framework for producing truly portable, native applications for Windows/Mac/Linux/Android/iOs from the same code project. Think FOSS child of Delphi from back in the day.
- StavrosK 9y agoAh, yes, I've heard good things about Lazarus. The problem with it is that it uses its own language (Delphi, as you say), so it's got its own ecosystem and things. No matter how good the UI toolkit is, it's not worth giving up all the niceties of a language with an extensive ecosystem, for me. It's a pity, because Lazarus does seem fantastic for desktop application development...
- martinrame 9y agoWhy do you think Lazarus doesn't have or interact with an extensive ecosystem?.
- StavrosK 9y agoBecause I don't hear free pascal as often as Python.
- squarefoot 9y agoAll it needs is a critical mass of users and the right support from some big names; if Go was developed outside Google it probably won't be where it is today. I'm not a fan of Pascal, though I really enjoyed using Delphi at work many moons ago, to me promoting Lazarus is also a way to tell other IDE developers that Delphi and today Lazarus got things right; it's not just about the language.
- aluhut 9y agoWow Skype with 109MB?! 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.
- 72deluxe 9y agoThis is odd. It indicates a badly written application with disregard for resources. 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"?
- aluhut 9y agoI see it that way: there is a new program for Signal which enables me to sent messages from my PC. It's the first version out there and it just works. This is much more then I've expected. 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.
- em3rgent0rdr 9y agoThe mobile aspect is important. Nowadays we are starting to see more non-Android Linuxes on mobile phones (like Post market OS or KDE Plasma), so it is important that messaging doesn't hog RAM.
- jorvi 9y agoThat is actually not a bad amount, the native Telegram macOS client hovers around the same. WhatsApp Web (also built on Electron) consumes a staggering 300-500mb.
- ivm 9y agoNative Telegram takes only 80mb on my Mac.
- interfixus 9y agoWow! A race to the bottom of the memory pool. Electron is several things which HN guidelines probably won't allow me to describe here. I avoid it whenever I can.
- andrepd 9y agoThat's all very true, but can you point to an alternative? If you were a small team with few resources, and you wanted to ship a cross-platform desktop app, what would you choose?
- interfixus 9y agoThere ar plenty of portable toolkits out there. Gtk, Qt, WxWidgets, Fltk, Tk, several others, with bindings to more or less any language you may care to think of. And Lazarus/FreePascal, of course. You may even embed some web-engine. It doesn't have to involve obscene amounts of megabytes and the selling of your soul to the Google monster.
- 72deluxe 9y agoI would choose wxWidgets personally. Easy to build the libraries, plenty of samples. Some bugs here and there but paired with a tool to layout UIs (like wxFormBuilder), you can get a lot done.
- 72deluxe 9y agoWhat constitues a "bad amount"? It is displaying a series of text onscreen, with a history of messages for each contact. What's it eating all that RAM for? My mind boggles.
- andrepd 9y agoI get what you're saying and I totally agree with the sentiment, but in this case I can let it slide. It's the only practical way to make a cross platform app for Linux, Windows and Mac. They simply don't have the resources to write and maintain (at least) three desktop apps. I can totally understand that a small company has to make compromises like writing their desktop apps in Electron. That large companies also do this is another story entirely.
- OldSchoolJohnny 9y agoI disagree completely, a single page application can be used on any of those platforms in browser and doesn't require Electron at all.
- yebyen 9y agoIs that really improvement if you need to run a browser to run the app? I guess most of us have the browser open all the time anyway, so adding an Electron app is just one more thing, but I know that Chrome on my machine soaks up a lot more than 130MB ... 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.
- nine_k 9y agoHow often do you even close the browser?
- JCzynski 9y agoAnd they had one already. Which no one liked.
- 72deluxe 9y agoI worked for a company that released control software for audio hardware. I was the only GUI developer (the only guy writing the frontend app), and there was another dev who wrote firmware and a network communication library that I used in the app. 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"?