Hacker News Reader

Comment by smcleod | Hacker News Reader

Other than the memory usage - these are problems I've encountered thus far:

  - It said it was 'Importing contacts and messages' when I signed in without first prompting me if that was OK.
  - Importing contacts and messages failed.
  - Manually importing contacts fails.
  - Conversations show up, but each message just shows as an error.
  - Deleting a conversation doesn't delete it, it just makes it as read.
  - Messages marked as read randomly reappear as unread.
  - Incorrect unread message count next to conversations list.
  - Messages often don't arrive at all, seems at random.
  - The application loses it's 'link' to your account seemingly at random upon launch and needs to be relinked.
  - Appears to use an outdated version of electron with published security vulnerabilities.

View on HN

I'm not trying to be snarky here, but .. did you report those on GitHub / to the Signal developers?

Link to lower the barrier: https://github.com/WhisperSystems/Signal-Desktop/issues/new

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?

Howdy, 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?

Yes I did as long as those 4(5?) starting with "Signal*" were all to count. But your other problems go far beyond that.

It's only 3 of them atm: https://i.imgur.com/lgJ8HZl.jpg

Equals ~169MB (I've just sent a picture)

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

"Software is getting slower more rapidly than hardware becomes faster."

-- Niklaus Wirth

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

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

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

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

Why do you think Lazarus doesn't have or interact with an extensive ecosystem?.

Because I don't hear free pascal as often as Python.

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

If you use QT and QML, you can write most (sometimes all) of your code in JavaScript.

Whether you consider JavaScript a sane language is up to you. :)

Lazarus: http://www.lazarus-ide.org/ It does multiplatform the right way, that is, compiling natively for every architecture instead of creating slugginess and bloat by forcing software to run interpreted or under VMs. Here are some projects using it. http://wiki.freepascal.org/Projects_using_Lazarus Also, both the IDE and generated software can run on different architectures, including ARM based boards such as the Raspberry PI and similar ones. I played with it also on Orange and Nano PIs with just one gig RAM: definitely not fast but useable; it should scream on the Odroid C2 or faster boards. My only wish is having something similar for Nim.

Yeah, as I said in a sibling comment, Lazarus is pretty much exactly how things should work. I share your wish, though, I wish they had Python/Nim/Rust/something bindings.

I think wxWidgets is still around and they have Python bindings (not used it, but have used the C++ wxWidgets a lot).

Xamarin + native UIs

As an end-user of software, which do you value more?:

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

Most end users have 2-4GB of RAM, it's not a choice, 'a' is the only option.

Electron lowers the knowledge barrier for people who are already knowledgeable in web development. For others, learning Electron can be far more complicated than learning, say, Vala or PyQt or Tk or even one of the plethora of Java toolkits, just as examples.

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

This 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"?

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

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

> This is odd. It indicates a badly written application with disregard for resources.

Everything about skype indicates that it's badly written. This is a text messenger that can't handle copy and paste operations correctly.

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

Native Telegram takes only 80mb on my Mac.

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

That'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?

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

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

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

300MB is what I see trying to run the MS Teams client. So I don't bother and use a browser instead.

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

I disagree completely, a single page application can be used on any of those platforms in browser and doesn't require Electron at all.

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

How often do you even close the browser?

And they had one already. Which no one liked.

I 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"?

How many updates did you ship per month?

Web dev tends to optimize for ability to change/improve quickly (for good and bad). Resource use on the computer typically not prioritized.

We did not ship often! Quality is more important to me than being able to quickly fling rubbish out of the door. Anyone can do that.

For audio hardware, you don't want to be grabbing software + firmware updates multiple times a week. You might be on tour with the hardware and changing it whilst on the road is likely a no-no.

I am now at a place where we ship daily, sometimes multiple times (different branches). The emphasis on decent code and quality is now higher than the previous place I worked. The codebase here is also incredibly vast by comparison.

We can still add features quickly but it is of little use if it is of poor quality. What's the point of bad software even if it is quickly shipped?

Telegram has found a way to deliver the same client on both Linux, Windows and MacOS using Qt. One does not need to consume hundred of megabytes of memory to achieve a cross-platform solution.

The telegram app for macOS is taking ~140MB of ram to display the welcome screen here.

> "They simply don't have the resources to write and maintain (at least) three desktop apps."

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

Most of these problems happened to me when I switched signal apps between phones. It all started working again within the same hour.

I had a load of problems when I first installed it and tried to migrate. A main issue was that it took a while for the "migrate" function to appear in the Chrome app.

Reply on news.ycombinator.com