Hacker News Reader

Comment by afandian | Hacker News Reader

When these kinds of things come up there's often complaint that desktop apps running in the browser are inefficient. As it happens, I agree. An old favourite of mine, Adium, probably never used 600 MB because I'm pretty sure my PowerBook G4 had less RAM than that.

But I think it's a mistake to jump to the conclusion that these apps should be written in a native framework rather than a web view. Slack is doing much more than Adium: web previews, document previews, pulling in pre-rendered fragments from the server and modular stylesheets. I wonder how much RAM Adium would have used to do the same things, and I wonder how much time the developers of an equivalent cross-platform app would have spent if they had been split trying to optimise lots of different platforms. They would essentially be re-inventing a modular layout and rendering engine (aka a web browser).

I don't know what the answer is. Maybe the detractors would prefer that the app did less. I know I'd prefer not to have previews and emojis, but I'm sure my colleagues find them useful.

(EDIT: Per reply below, turns out Adium did use a web view for presentation!)

View on HN

I'll second this and note that Telegram, an app actually written in native code, is currently using ~500MB on my machine right now. I hate to be the one to say it (mostly because I just don't care about the ensuing argument), but I think most people who decry Electron/et al don't actually have that great of an understanding of how memory works. I say this as a guy currently sitting here writing an iOS/macOS app in Objective C by choice.

Also, to echo your point: yes, the amount of free stuff you get in a web browser would be an absolute nightmare to reproduce in some native code environments (especially cross platform).

The only reason I'm still wary of running any Electron app for long periods of time is because I do end up feeling the same sluggishness that I feel with Chrome open after awhile, and I don't think there's much that can be done about that. With that said... I've been using sluggish apps since the Windows 98 days, this isn't a new concept.

> Telegram, an app actually written in native code, is currently using ~500MB on my machine right now.

I took a look at the Telegram source code right now, and…I'm not impressed. It appears to be written without a real knowledge of how Swift or Cocoa works, has no consistent style, and seems like it reinvents significant portions of standard APIs. Like anything, the benefits from migrating to "native" only work if you actually utilize it correctly.

Meh, there's often reasons to reinvent a portion of an API. You'd need to be more specific about what you see there that's an issue.

I also pointed out Telegram because people, consistently, in every one of these threads, trot it out as an example of a native chat app (I don't count the Qt version in any of this, because it does not in any way feel native on macOS).

To be honest, I welcome anyone to point out a competing cross-platform chat application that does almost as much as Slack does and doesn't eat up memory.

No-one else doing it "right" is not an excuse for anyone to do it "wrong".

EDIT: Leaving aside the question of whether the other multi-platform messaging apps also do it that poorly, and merely running with your assertion to that effect. I have neither the time nor the inclination to gather data on that question.

No one else doing it right can be an argument to show that its because no alternative is much better, and so Electron is actually the possibly right choice. It still being too slow or memory hungry for your liking still remains though. But it seems that there might not be an obvious solution to this that does not compromise on features.

"No better alternative" != "right". As you observe, a compromised choice is still compromised.

All software engineering choices are compromised choices made from carefully considered trade offs. To argue they made the wrong choice, you have to show they made the wrong trade offs. I understand you mean the user experience is still not ideal, but when would it ever be? When will performance or RAM usage be "ideal"? What does that mean? Should it compute in 0ms and use 0% RAM? There is no right ideal, or true ideal. The idea of an ideal is itself a choice of trade offs. Your ideal could be that you absolutely need under 20ms response times on all UX actions, while never exceeding 100mb RAM. And that could be ideal for you, but might still not be the right ideal for me, hoping to run it on a modded gameboy hardware. And if that was the case, can you compromise on feature? If not, and its not currently technically possible to achieve your performance ideal and have parity of features, then what? Is the right choice then to not release a desktop client for slack at all?

So if you know a way to achieve your ideal, then you can propose that alternative, and you can say, here is how, without much more cost of development, you can achieve X, Y, X improvement on performance while keeping all features. But, if you do not know, and have no known examples, it could indicate that it is not currently technically known how, and thus impossible with the current hardware and software knowledge at hand.

I'd also say that in the case of Slack, their ideal is probably defined more in terms of profits. So it could be said to be the right choice, simply because of how popular their service is and has remained, even though they picked Electron for their desktop client.

Nothing is perfect, every choice is a compromise. As a company, there are limits to how much time and effort is spent while growing their business. How much RAM is used is very low on the list of considerations.

I would be fine with the amount of RAM used, if Slack didn't also materially reduce my battery life, by keeping my CPU — and fan — spun up. Charge-discharge cycle counts are a limited thing. They're directly shortening the lifespan of my hardware, doing that.

Is that really your argument? Slack has a material effect on your hardware life - as opposed to all the other usage? Is slack the only thing you're running?

Why not just use another tab in your existing browser then? Or another service entirely?

Either way, it doesn't change anything in creating a widely used application for the least amount of time and effort. The vast majority of their users will not care or even notice if there was a more efficient native app.

It is the only thing reliably using 10-20% of my laptop's CPU, while idle. Having the Slack iOS app even open drops my battery at least 10%/hour. Even Facebook's app or using a mapping app, actively listening to the GPS birds, don't do that.

My employer dictates the choice of communications tool. I don't just get to "pick another service entirely."

EDIT: And their site's 2FA (which I'm required to use, because $work) also reliably gives me "too many login failures" on the first login attempt, so using it in a browser tab is a non-starter, even without also losing desktop notifications.

With the amount of money they've been given, both by VC and by customers (I know what we pay them per month, and although we're not a small company, we're far from their biggest customer), this quality of software and service is absurd.

> there's often reasons to reinvent a portion of an API

Yes, but I don't feel that a message app really needs to do this to the extent that Telegram does–they've managed to make their app look out of place on macOS.

Mmmm, that's really vague though - what exactly feels out of place? The only applications I use on a daily basis that feel like they're "Mac" are Safari, Messages, Xcode, and I guess Finder... all of which are built by Apple. Maybe Paintcode counts too?

The rest of the apps I find myself using don't use those same UI/UX patterns/designs, and I don't think it matters that much: Photoshop, Terminal, Telegram, Bear, Fantastical... the list goes on. The applications that keep me coming back are the ones that are smooth and don't interrupt my train of thought (most everything here), or have some big use case (Photoshop) that keeps me coming back.

I'll also point out one more time that Telegram is what people bring up every time this discussion rolls around, so they're clearly doing something right and people must not think it looks _that_ out of place.

Hell, I'd argue that the consistency of UI/UX on Apple products matters more for the initial purchase and wow-factor than it does once a user has settled into their environment. Every application does not need to function and look exactly the same.

To be honest, this all feels like moving the goalposts, and is why I usually refrain from getting into these discussions.

I'd challenge that. I have been using the Telegram native client on Windows since ~3 years and I don't remember having it ever going beyond 100 MB usage of RAM or ANY spikes in CPU usage (usually ~60 MB and 0% CPU). It usually sits there, quietly. Maybe its using more RAM when I take a call with it, but since its going back to normal after I finish (or it's always just low), it doesn't matter.

I am using Slack since more than 3 years too. I have tried their web-app, desktop client, iOS app, everything. The iOS app is pretty good and gets constant love. Both the web app and desktop client are pretty much equal in performance: laggish and slow. My laptop has only 8 GB RAM and a 3-4 years old CPU. The next Lenovo I'll be getting is available with max. 16 GB RAM.

I have switched to the web app in my Chrome since ~2 years, because after all, the desktop client does eat more RAM, since it will have 2-3 extra processes, whereas running as a Chrome tab, those processes already exist anyway (i.e. GPU process).

To have the Slack tab always open as a single dedicated window, without the toolbar and tab bar etc. I use this as a bookmark:

  javascript:(function(){window.open('https://your-company.slack.com', 'Slack', 'scrollbars=no');;})();

I am also using the WhatsApp web app (also tried their 'desktop client' for a while), it's about the same experience as with Slack. Crappy.

Coming all the way from ICQ, IRC, Miranda etc. Telegram is the best chat client I have ever been using. The iOS app is great and about the same quality as the WhatsApp app (which is maybe slightly better), but since most of the time I'm infront of a real keyboard, I'd rather use the desktop client, which is just really snappy. The product design comes close to Apple products. All the drag&drop features, selecting of multiple messages/pictures, search, hotkeys ... Someone really did an effort and thought about all these small details. You can't imagine how easy it is to show all sent photos, easily browse through all of them with hotkeys and they show up instantly, or show all sent URLs, and so on. It is so good, that many times, I'd rather get up from the sofa and sit down at my desk to type a 2-3 sentence message to someone, than using my iPhone (WhatsApp or Telegram or iMessage). Oh and it has bots! I actually did one! Announcing delays and stuff for public transport in my town, using a server with php that is doing all the web crawling. I'd never even think about doing that in Slack.

Aahhhh, I just saw this, sorry.

I'm happy to be wrong! I think one thing that sucks about these discussions is that everyone gets different results on their machines and it's difficult to pinpoint why memory usage might be so high - e.g, I have a slew of cryptocurrency chats open, so maybe Telegram is just doing that much more work or something?

> Maybe the detractors would prefer that the app did less.

Sorry, that argument just does not hold water. On my Mac currently, MS Outlook is using 483 MB versus Slack using 704 MB, with just one tab open. For all of Outlook's bloat, one can hardly say it does less than Slack; it's just a glorified chat app for pity's sake.

Even IntelliJ is using only 2x as much RAM as Slack with 4 medium sized projects open and IntelliJ is orders of magnitude more complex than Slack.

You're wrong. Slack is doing much more than Outlook.

Yea a glorified chat app with video chat, audio chat, screen sharing and screen takeover remotely, file uploading, 3rd party integrations doing multiple things depending on your team setup, etc. I'd hardly call it a glorified chat app.

Messages.app does all of those and uses a tenth of the RAM.

There're IRC clients that do half of that (unless IRC got audio and video support at some point) using < 1% of RAM or CPU...

Yeah, but it doesn't run on my PC, or my phone, or in a browser.

I don't need it to run in a browser or PC, and it works on my phone since I have an iPhone. You needs may vary, in which case you might just stick to SMS which is cross-platform and lightweight.

Interestingly, Messages.app on macOS actually is a webview (well, the chat log portion of the window).

do you have a source?

A quick glance at the view hierarchy (Accessibility Inspector.app can do this) shows that the chat view is just a web view.

Interesting! Thanks :)

You can control people's screens through Messages? And you can write simple webhooks and bots with a few lines of Ruby? Please send me some links, I'd love to do that.

Screen sharing w/ control: https://support.apple.com/guide/messages/screen-sharing-icht...

As to web hooks and bots, if you really think that necessitates having it be a bloated Electron app, I don't know what to say.

AppleScript is still a thing, right?

Yeah, it is, but I definitely wouldn't call it a webhook / bot alternative. Having used AS with Messages.app before, it definitely isn't very useful for anything but very basic stuff.

I'd be interested to see a study of how many users actually use those features. The company I work for mostly switched from using Skype for chat to Slack and I don't think I've ever done anything with it except send and receive plain text a sentence or two at a time.

The only reason we are trying to switch from Skype is for the persistent and searchable history. I say "trying to switch" because about half the company prefers Skype messaging and so now we have to have two clients installed.

My team built a couple bots that help us keep track of issues we are working on, schedule releases, etc. We also do all of our meetings on Slack; when you're on a call it automatically updates your Slack status to reflect so, that way your teammates know you are busy.

Whether people use all of Slack's potential or not it's a different discussion, but I'd rather have the ability to do more if I wanted to than having to look for yet another tool to solve a small problem.

Don't get me wrong - I'm 100% in favor of extensibility through plugins and bots.

I don't think that means that the default client can't be lean and efficient.

does video always on? This is just WebRTC and it is not using 500mb of RAM while idle. Integrations? They all are constantly keep something in memory? Most of this logic is done on the server and app is just a mirror of a server state.

> video Chat, audio chat, screen sharing, screen takeover, file uploading.

All of these are dormant features.

> 3rd party integrations

Which are processed on the server.

The complaint is that Slack uses an ungodly amount of resources when they're just sitting idle consuming new messages.

That's why I'm developing eul, a lightweight native desktop client for Slack, Skype, Facebook etc:

https://eul.im

It's only 4 MB and handles tens of thousands of Slack messages in one chat without lag.

1.0 release is going to be out in early November.

This sounds promising :) Btw, you have a Gmail icon on your site -- I'm assuming that implies Hangouts support?

Thanks! :)

No, it supports Gmail via the Gmail API. Soon it's going to have a full email client built in.

One thing that concerns me about any 3rd party chat application is that it's difficult to know if my data is secure. Any thoughts on open sourcing your application?

Yes! I want to make it open source, from my experience that's the best option for all parties. Unfortunately it won't be possible to open source some parts of the app.

I'm setting up a company right now to increase trustworthiness. Like the home page says, no data will ever be shared with anyone and soon it will be possible to verify this.

> Unfortunately it won't be possible to open source some parts of the app.

Why is that? Are you licensing code from somebody else?

Sorry, but it doesn't work for me at all. When I try to add a service, I get the login screen for few seconds, and then the whole window turns gray and I can't type anything, the only thing I can do is to close it. Tried several times with different services. Tried macOS version on High Sierra.

That's weird. What's your hardware?

MacBook Pro, early 2015, 8GB of RAM.

How are you writing it? C++?

"Native" does not just mean "use the native toolkit" or "write in non-web tech". This app looks nothing like macOS or Windows apps. Most likely, none of the features users are accustomed to will work.

True, but it will get better with time.

The fact of the matter is that in the things that matter, a web view is more native than this—and in practice probably always will be. :-(

No. That's actually almost never true. It certainly isn't what I meant.

Screen readers. System themes. Keyboard shortcuts. Text rendering. Visual effects on interaction. The list of things that go into making even a simple text box is surprisingly long, and varies a lot by operating system and over time.

Browsers—well, Gecko and Edge; WebKit and Blink aren’t quite so good at it—tend to do things properly or to a remarkably high fidelity. They put enormous amounts of effort into getting it right, because it’s worth it for them. Something like Qt also puts a lot of effort into getting it right (even if it still commonly requires the developer to make certain choices to use that rightness).

But something like this, not using any GUI toolkit? Games can do it, because they aren’t trying to fit in with the everything else, but regular applications just shouldn’t do it. I have never seen a single one that was even good, let alone great. They always fail to handle various important things properly, and so tend to wind up painful to use or even unusable for many users.

If you care about your users and are not making a game, the sad truth is that drawing all the controls yourself is irresponsible.

> If you care about your users and are not making a game, the sad truth is that drawing all the controls yourself is irresponsible.

I agree, but the solution is not going to web, but instead using the OS provided UI toolkits.

Looks awesome! I saw you said it was written in Go and I've been looking for a good Go GUI library. Which one are you using?

I'm drawing UI manually with OpenGL. It's not easy :)

It would be much easier to focus on the core and allow other developers to connect native UIs for each platform.

OpenGL is not accessible and the current UI looks hacky.

This looks really nice. Two issues:

1. Downloading embedded web browswer had been at 0% for a few minutes. At I went to close it, I noticed the counter creep up to 1%. The download is _slow_!

2. Not open source. I cannot trust a proprietary app with my login information to my communication channels.

Once the app is open source, I'll happily give it another try. Thanks!

If I’m not mistaken, the actual chat contents in Adium were rendered with web views, and its configurable message styling was done with HTML/CSS. The whole program wasn’t stuffed in the web view though, it was a presentation layer on top of a native backend.

EDIT- here’s a source on that http://meyerweb.com/eric/thoughts/2005/12/19/adium-chatting-...

Yes, this is what the native macOS Messages.app does as well. On my Mac, with relatively heavy usage, I'm at around 100 MB of RAM.

It clearly works pretty well that way. Textual (Mac IRC client) is the same setup.

Slack, on the other hand, feels like JavaScript frameworks piled three or four deep, often getting its UI out of sync with the actual state.

Chats/channels will briefly flash (1) unread in the sidebar to tell me about my own message that I just sent, or I’ll continue to have a blue “10 new messages” banner in a conversation that I’m actively participating in.

I use it because it’s convenient, but there’s definitely room for improvement.

Wow, that's crazy. The iOS Messages app is native. I'm only familiar with iOS development... is AppKit that bad?

UIKit is noticeably better than AppKit but I doubt this is the reason why Messages is webview based. I don't know the exact reason behind it, but my guess is that they stopped caring about updating it when the people working on it either left or moved over to other projects.

I've taken that same guess after the new fancy effects and animations for iMessage got fully implemented in iOS 10 and barely supported at all in macOS Messages. It seemed like an afterthought on the Mac.

Yes, this is accurate. Adium’s message views were almost entirely HTML and CSS with very little JavaScript. The bulk of Adium’s “brains” were written in Objective-C (and plain C, via libpurple).

Well! You learn a new thing every day.

You are making a false assumption that more features is something like geometripential in the amount of memory it should use.

It is a list, with some images. They have Rubegoldberged themselves into some Sisyphusian box of poo while they expect us to row the SS Honeybucket to work and back.

You know what my solution is for when I need to slack? I RDP to a VM running Slack. Mother of Lord! How about Slack sell lil USB ARM computers, like a chromebit that just runs Slack? Maybe I could pair them with my Snapchat glasses! Modular, yes you can!

> geometripential

please define this new word

Guessing: Between arithmetical and exponential? Geometric/multiplicative?

> Maybe the detractors would prefer that the app did less

I would. Unfortunately with these browser-based app solutions, rarely are features and resource usage proportional. Therefore, runtime configuration doesn't help that much.

I personally would like to see Chromium take a more staunch approach at memory reduction.

Does Slack actually render any externally-provided HTML?

Last I checked, they had full control over all the rendered content, including the snippets that show up when you paste, say, a YouTube video. They do use HTML UIs here (e.g. the embedded YouTube player), but is this stuff coming directly from the upstream source or from Slack? I would hope the latter. After all, it seems you can paste a direct link to a video file (e.g. .mp4), and Slack renders its own video player.

I never understood why Slack didn't spend their many billions of cash rewriting the desktop app with something like React Native. Even if they do need to render third-party snippets, they could still embed web views for those instances, which should hopefully be in the minority.

> I know I'd prefer not to have previews and emojis, but I'm sure my colleagues find them useful.

Of course if we'd use an interoperable standardized protocols instead of walled-garden apps, then your colleagues could have their cake and you could eat yours too by allowing everyone to choose a client based on their preferences.

WhatsApp web and Telegram do much of the same (well, besides the WhatsApp web app being nothing more than a front end to your phone as backend) yet WhatsApp uses 500mb.. Telegram (the native macOS that is) consumes around 100mb. So yeah, Electron is bad.

Reply on news.ycombinator.com