Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Standalone Signal Desktop

signal.org

Post reply on HN
Print view View original

271–280 of 320 posts

Re: Standalone Signal Desktop

#271

Post by 72deluxe »

andrepd wrote: post #266
72deluxe wrote: post #218

Earlier quoted context omitted.

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.

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…

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

Re: Standalone Signal Desktop

#272

Post by bogle »

jorvi wrote: post #225
72deluxe wrote: post #218

Earlier quoted context omitted.

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.

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.

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

Re: Standalone Signal Desktop

#273

Post by jcelerier »

kethinov wrote: post #209
pjmlp wrote: post #208

Earlier quoted context omitted.

C++ is not the only option to write native applications. Electron is an hybrid codebase to start with.

All the options you listed require two or more programming languages. Electron apps can be written entirely in JavaScript, requiring zero context switching between multiple programming languages, as well as sharing code on the backend and frontend. Hence the popularity.

> All the options you listed require two or more programming languages.

You can write Qt apps entirely in C++ or entirely in QML (of course you can mix and match both... in my experience whatever the environment you always need to resort to native modules at some point anyways, eg numpy, opencv, etc and Qt makes exposing them to Javascript dead easy).

Re: Standalone Signal Desktop

#274

Post by interfixus »

andrepd wrote: post #267
interfixus wrote: post #251

Earlier quoted context omitted.

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.

Re: Standalone Signal Desktop

#275

Post by 72deluxe »

wh313 wrote: post #222
72deluxe wrote: post #218

Earlier quoted context omitted.

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.

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.

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

Re: Standalone Signal Desktop

#276

Post by yebyen »

OldSchoolJohnny wrote: post #268
andrepd wrote: post #266

Earlier quoted context omitted.

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…

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.

Re: Standalone Signal Desktop

#277

Post by acdha »

scott_karana wrote: post #142
acdha wrote: post #73

Earlier quoted context omitted.

You are willing to run their code on your computer with full access to your data but not in the heavily-sandboxed browser environment?

Verbify didn't say that at all. It's ludicrous that you can't download a security-focused app when your browser settings are unusually secure. ;)

> It's ludicrous that you can't download a security-focused app when your browser settings are unusually secure. ;)

Security is about threat models: if you don't trust the code they write on their website, you shouldn't trust the code they shipped in the app.

Re: Standalone Signal Desktop

#278

Post by jononor »

72deluxe wrote: post #271
andrepd wrote: post #266

Earlier quoted context omitted.

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…

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…

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.

Re: Standalone Signal Desktop

#280

Post by 72deluxe »

jononor wrote: post #278
72deluxe wrote: post #271

Earlier quoted context omitted.

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…

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?

Post reply on HN