Hacker News new | past | comments | ask | show | jobs | submit login
Where’s all my CPU and memory gone? The answer: Slack (medium.com)
275 points by thegeomaster on July 27, 2017 | hide | past | web | favorite | 277 comments

Want to make an app that people use in the background? Music player? Chat app? Backup? Antivirus?

Then for gods sake make it lean. Set a resource budget and stick to it. Don't assume your product is a special snowflake that your users will want to waste resources on.

The easiest way is usually to just use a native toolchain and UI. Your users don't care how easy it is to find js devs.

...and remember that Quake 3 required 64 MB to run, while Half Life managed to run on 96 MB of ram.

I'm pretty sure Half-Life required a lot less than that. The first PC I played it on only had 16 or 32MB of RAM.

Those games were all written to "bare metal", talking to Win32, DirectX, etc. Most modern apps like Slack use a pile of giant frameworks which handle most cross-platform portability, at the cost of massive explosions of resource usage. It's a lot more work to write platform-specific code without those frameworks. I don't defend their choices, they're big enough to pay that cost, just explaining where this comes from.

> It's a lot more work to write platform-specific code without those frameworks

Qt/QML abstracts over a ton of platforms, lets you write UI code in JavaScript, is extremely easy to pick up, has a WYSIWYG drag-n-drop editor and consumes a small fraction of the resources Electron does.

The overuse of Electron is not because everything else is impossibly hard; it's just old-school fashion-driven development.

I've got a lot of experience with Qt, since I ported Google Earth from Windows to mac and linux, and it was Qt based back then. You have the problem of having slightly non-native feel because Qt has to code around platform differences to present a unified API. When we first released the app, we took a lot of criticism because of its non-native feel on all platforms (except for Linux, which doesn't have a native feel). So, if you want a top-quality app, you're probably breaking it apart into a platform independent core and then writing your interface separately on each platform using native API's. I wish that the cross-platform abstractions worked well enough to be indistinguishable from a native well-coded app, but we're not there yet.

I didn't suggest Qt as an alternative for native toolkits to achieve a native look and feel; while it can be done it's a lot of work. I suggested Qt (specifically, QML) as an alternative to Electron, which doesn't care about native look and feel.

Bloat is making me so angry that I'd take an as400 textual interface as native feel any day. The web era is one step too much in the wrong direction to me. I enjoyed the hyper genericity of the web, but I'm tempted to say we need a little bit more of the flat and trickful things of the past.

You guys should remember that a lot of crap we write nowadays is a consequence of bloated languages and "move fast break things" attitude.

Doom and Half life were at their core exceptionally optimized C.

Behind the trees you don't see a forest: Half-Life used 32MB of memory on 1024x768 display. By 4 or even 2 byte color it is 2MB just to store picture output. Modern apps work with 4k2k*4byte color, which on itself is 8 times more memory.

I think I understand the point you're trying to make (modern apps draw to larger screens, and therefore must use more memory) but this is a poor comparison for a number of reasons. The most obvious of these reasons is that graphics cards are leagues ahead of where they were back in the days of Half Life. Sure the framebuffer takes a bit more memory, but a 4k frame is only about 32MB of memory at 32bits per pixel.

Anyway, you're root argument is still somewhat valid: Half Life was working with some really tiny constraints compared to modern machines, and did amazing things within those limits. Modern apps, were they coded to the same level of optimization as Half Life, should be much, much smaller and more efficient than they are. But as it turns out, the human cost of developing video game software is high, and the one area where Electron truly succeeds is in its ease of use. By driving development costs down for non-game apps, it balances out its high resource usage, and to a company producing software, that's enticing. I think that's awful (and would prefer to run optimized software personally) but the industry seems to disagree with me.

So, 2 MB for the display. And then there are the textures for the walls, plants, people, monsters, etc. And the vertex data for each of the models on the level. And the level itself. And then there are the light maps for static lighting. That's at a minimum. After that there is the memory required for the AI. Much of the models and textures won't be used in any given scene, but might get used in the next frame, or the next half second, and to avoid long pauses when a new model is loaded they all have to be in memory. If Half Life could have been done in less memory, I'm pretty sure they would have done it. It probably started off using a lot more memory and they probably spent a lot of time getting the memory down so that your mid-class machine could play it.

So that accounts for 16MB of the 1500 used, where is the other 1484 going?

Half Life 1 run on 32MB ram.

> Your users don't care how easy it is to find js devs.

Their user do absolutely care about UI/UX. If you're going to implement it native without all the "free" things you get from the web stack, and its popularity, the UI is most likely going to suffer.

I don't know about other platforms but on MacOS native apps are way better designed (looks and usability) than the electron crap that is available. So I'm curious, what makes you say JS devs are better at designing apps than native devs who know how native apps work?

They also care about battery life and system performance, they just don't know to blame Electron for any problems they have with those things.

What evidence do you have that js devs are any better at ui than native devs?

Most of the web is a usability nightmare.

On Windows we have WPF.

Compared to the web stack, it packs much more free things relevant to desktop development. The examples of such things are animations, composition, data binding, pixel shader effects, and vector graphics.

Also WPF renderer is based on Direct3D, I would expect better performance.

Telegram for macOS is fine except it could look and feel more native imho

The solution to all of this is to use React Native, or a technology that is based on its principles to the desktop.

I tried to use Slack multiple times and it is the same - laggy, slow experience that caused me to completely leave it. I would assume more from a tool praised by devs, to be honest. The whole experience was for me super negative, and it seems that Slack is mostly re-wrapped IRC, thus getting overwhelming support from IT guys in large corporations.

My laptop is only i3 with 6 GB Ram and some integrated graphics card, but I would assume this is enough to run a chat app, if the machine can flawlessly run Flash games and never cause an issue when I develop apps...

Things are getting out of control. Some of my non-technical friends are already moving into 16 GB of RAM on their new laptop purchases. For surfing the web and watching movies...

The worst thing is not just memory consumption, but sluggish UIs. Everything is turtle slow. I notice a significant lag when typing on their machines no matter how much RAM or CPU you have.

I run a WM (XMonad), Firefox (vimperator), a terminal (urxvt) and Emacs, with no actual desktop environment (but all services, including firejailed applications). Without opening Firefox, I'm comfortably below 200 MB of RAM. And Firefox is not a memory hog either, if setup and used with care.

Even more, before starting X, I'm around 128 MB of RAM, yet I can do most stuff inside a text-mode Emacs.

An additional benefit is robustness. With fewer components things hardly break, and when they do you can easily fix them. Especially if you use a Nix-style package manager and system configuration.

Not a setup for everyone, I know, but an average HN reader will have no problem putting it together. If friendlier GUIs are still your preference, I believe some lightweight Linux desktops are worth a shot. Last time I tried Xfce, it was simple and lightweight. Even my old dad was able to adjust to it quickly.

it's the weird memory logic of HN biting again:

"Memory is cheap, development time is expensive"


"What do you need more than 16G of ram for?"

These two things are not compatible, but every time a story comes up about new laptops (macbooks being a prime example) everyone jumps on the guy who asks for more than 16G of ram while routinely excluding things (like browsers) that just chew memory.

It is almost like hn is made up of different people with different opinions.

Yeah, if I were setting up messaging at a company, having witnessed the true total cost of these single-source solutions, I would set up IRC and/or XMPP. For some companies, the costs are lower with Slack, and I think that's where it shines; but I am fed up with it.

That said, the author of this article is actually just trying to promote his startup. I think that's fair enough, but I think he should disclose that more prominently than just having it in his byline.

Should Adobe kill Slack ?

Slack is a heaping pile of shit.

I understand it lets you conduct text chat.. and basically works for that.

But I don't understand the fawning.

It's a massive resource hog. People have inadvertently DoSed my browser by pasting a message rate that any native application like irc or jabber would yawn at.

Windows 10.

My browsers are consuming ~4GB of memory right now. The Slack app is taking up 130MB, currently signed in to two teams.

To be fair, Outlook, which manages 3+GB of Email, is only taking 60MB, so old school does win out.

Slack starts a V8 instance for every team you sign into. It is absurd on my W10 machine.

Running it on Edge is significantly better on battery life and it feels snappier.

Slack's success comes from their buttery-smooth onboarding process, not the technical capabilities of their product. It's just so easy for a non-techie to set up an account with them.

Discord is a superior product to slack in every way I've ever used it.

Including on boarding, it beats slack in it's core strength.

The thing is discord has a stigma for "gaming" and slack for "work", and I can't get people to switch for that reason.

It's so dumb.

> The thing is discord has a stigma for "gaming"

Have you looked at discord's homepage, they specifically say its "Free Voice and Text Chat for Gamers"

Superior in every way? but all your accounts over each guild on discord is directly linked. Compare to slack which are kept all separate, with different user information, display pictures and the like.

It's easier to manage your presence on slack than it is discord, because discord offer no assistance to those who handle multiple accounts or identities.

As with other competitors, teamspeak solved this, irc doesn't have this problem at all. Skype does, doubt they will do anything about it, Microsoft have made another solution for team management

You're learning an important lesson about marketing.

There are many examples of inferior products winning due to marketing.

Windows is one of them, x86-64 is another, AWS is a more modern example. (people are still very much on the hype train here though)

Edit: I knew people wouldn't like me pointing at AWS;

> x86-64 is another

Inferior to what and by whose standards? Itanium?

Itanium did get rid of a lot of the cruft of x86, but I'm talking specifically about PPC

> Slack is a heaping pile of shit.

I agree 100%. But it is still my preferred messaging platform, much better than Skype for Business, lync, anything else I have used.

We rolled out 'Skype for Business' and my lord is it a steaming pile of shit. Ignoring the fact that the UI is annoying, lacks basic features, fails to perform simple tasks like sending images, it's really the routing that makes loathe it.

Have the app on your phone and your desktop? Step out of the office for a minute and get a message. See the message preview in your notification and tap it. It opens the app to an empty chat because it has now completely forgotten the message and it's sitting on your desktop.

Everyone in our group got so fed up we set up a private team IRC server to route around this horrible platform.

Skype for Business is Lync, with the Skype logo crudely painted on top. And Lync is...essentially a MS Outlook plugin.

I now run Slack in Safari on my Macbook Pro.

In Activity Monitor on macOS there is an "Average Energy Impact" metric. I noticed that Slack had a value of 34. The next highest was Chrome at 23, and that's with 200+ tabs open across multiple accounts and windows.

Safari runs with a tab per Slack team, and it's Avg Energy Impact is 1.

I also gave up running the Slack Mac app, and now use it exclusively on a browser/iOS.

One issue I haven't figured out in Safari specifically is that it suspends tabs, which is why its so low on energy impact. A few min away from the Slack tab in Safari means that I'll disconnect and appear offline.

I haven't run into that issue. Maybe background notifications prevent the tabs from being suspended?

MBP '15, 8GB of RAM:


I rarely have more than 10 Chrome tabs open. How many Slack teams do you have open? Do you have the latest client?

I uninstalled the app, so I can't post screenshots anymore. Yes, I had the latest client with 4 teams, I also have a 2015 MBP 15", but with 16GB of RAM

Amazing that people are OK with this, or the misbehavior of Electron in general. Bring back IRC indeed...

I love IRC, I even run my own IRC network, but IRC in 2017 is indeed woefully dated.

To my mind we need something which is a little bit more mobile friendly- with support for replaying history etc;

IRC "could do this" with bouncers and such, in fact I do this myself, but it's not very clean- and if you see it from a protocol perspective it's all hacks on hacks.

A clean "IRC for 2017" style protocol would probably wind up looking a lot like matrix, so I'd rather we rally behind that.

My team uses matrix, it's loads better than Slack.

It's a shame that Electron isn't modular. I think there were some attempts to make modular versions that would lead to smaller bundle sizes and resource consumption. I think the reason why Slack is os successful with such a poor performing app is most people using the app have machines provided by employers and they're good enough to handle the app without issue.

That's always been the refrain for why released software doesn't perform well, and it was a problem traditionally mtigated by software testers with a wide variety of hardware. You see the same thing on the web with slow-loading sites that clearly weren't tested outside a first-class first-world 4G or wi-fi connection.

Props to Facebook for mandating low-bandwidth testing

Use Slack on the browser. Works great. No performance or resource usage issues.

Not sure why so many people use the desktop app. It's an Electron app so of course it will suck up everything.

Maybe https://github.com/42wim/matterircd could be useful.

Originally made for mattermost, but I'm adding slack support (currently in master and only basic).

Slack has an IRC gateway (or XMPP). You can use that and your favorite IRC client. In fact the most usable way is this way.

So, I cannot reproduce his findings. My system (same setup, Slack native app on macOS) is consuming 1.6% CPU, about 0.6 GB memory, and has avg. energy impact of 3.22 with current being 0.0.

The memory is high, but a lot less than Chrome and nothing near what the author is seeing.

Only differences I can see:

- I'm signed into two accounts while the author is signed into 11.

- The author is CEO of a competing messaging platform.

More experiments might be needed here.

I'm signed into 6 accounts right now, but I only visit 3 regularly (and Slack supposedly no longer keeps all teams in memory if you're not looking at them), and my average energy impact is 10.07. That puts it solidly in the #2 spot (with #1 being Xcode, which makes sense because I'm compiling all the time).

I currently have 8 Slack Helper processes, one of which is sticking around 6-7% CPU, but the others are between 0–1%. Slack itself is around 4% (this is without me interacting with it, and with no animated GIFs visible on the screen right now).

FWIW the impact of animated GIFs (including animated custom emoji) is pretty high. Switching to a channel where there's 5 tiny animated custom emoji pushes CPU usage up to 18–20% for Slack Helper, pushes Slack itself up to about 9–10%, and makes my Energy Impact jump to 40–50 (which is insane).

The authors company isn't a Slack competitor, it's a real-time data platform. Otherwise I imagine they wouldn't be using Slack for their internal messaging.

From the page:

> Matthew O' Riordan is CEO and Co-founder of Ably. Ably is a platform that makes it easy for developers to add realtime messaging... to their applications.

Slack is realtime messaging. Ably is realtime messaging. They are competitors - the only question is how direct.

Slack is chat, its messages are sent and read by humans. Ably is a developer API, its messages are sent and read by machines.

Slack has a shiny user interface and a bunch of nice enterprise features. It's something you'd have everyone in your company sitting on their machine all day.

Ably is something nobody will ever see. It's an API that underlies other people's applications. Hell, Slack could run on top of Ably.

They're absolutely not competing. You're either misreading or deliberately misleading.

...no? Google and Algolia aren't competitors.

So what? Doesn't mean what he says is false. This sort of ad hominem attack on the author and not the argument is a logical fallacy.

> The author is CEO of a competing messaging platform.

I went to their website, it doesn't seem like that kind of messaging.

> Ably is a realtime data delivery platform providing developers everything they need to create, deliver and manage complex projects. Ably solves the hardest parts so they don’t have to. Our 100% data delivery guarantee offers unique peace of mind to stream data between apps, websites and servers anywhere on earth in milliseconds.

Slack currently uses a separate webview for each team you're signed in to[1]. They're apparently working to optimize the app for those running multiple teams. People like to hate on Electron, but in this case Slack's implementation of multiple teams deserves more blame than the underlying stack.

[1] https://slack.engineering/reducing-slacks-memory-footprint-4...


>> This memory footprint increases as the user signs into more teams, as each team runs in its own webview.

>> Each of these teams is running the full JavaScript web application and maintaining and updating the DOM tree as the state of the team changes.

>> Work is underway to fix the underlying factors affecting client memory consumption

>> Exploring running all teams in a shared context to eliminate the overhead of one webview per team.

> a separate webview for each team you're signed in to

So then shouldn't it be the same penalty as having 11 pages of Slack open in Chrome? That seems like something not too extreme to me.

I'm not certain of their use of the word "webview", nor exactly how multiple rendering windows work in Electron. In theory it should work the same as multiple tabs in a single Chromium instance. In any case, the Slack app is very heavy. You should be able to manage all your teams in one tab with a single instance of the app rather than a separate tab with the entire single-page app having to be loaded over and over again.

Hi Toby

Quick responses:

> I'm signed into two accounts while the author is signed into 11.

Yup. Also, see a subsequent update at https://medium.com/@matt.at.ably/wheres-all-my-cpu-and-memor.... One of the Slack developers got in touch and confirmed this issue is resolved in beta 2.7.0. I tried it and it is indeed.

> The author is CEO of a competing messaging platform

Ably is not a competitive platform in any way whatsoever. We are a realtime data distribution platform, we have no consumer apps or products you can use, only a low level platform-as-a-service for broadcasting realtime data.

Dunno man: http://i.imgur.com/u2KZEhZ.png

Windows 10 memory compression saves them a lot, but this is absurd, chrome/outlook use roughly 30% of this.

I'm on Windows, and I see a similar thing. 0% CPU, ~130MB of RAM in Task Manager. Most of my 16GB of RAM is being consumed by my mess of open Chrome windows.

Just looked at it, Windows 10, the main process says 83MB of RAM and 0% CPU... but scrolling down in the background tasks there is EIGHT background tasks, each consuming atleast 0,5% CPU and a staggering 943,2 MB of RAM...

And its just running as a tray icon.

It seems they are trying to hide what they actually use.

For my situation, I had four or five background tasks, each consuming < 50MB and 0 CPU.

Maybe the teams that he is on tend to send images (in particular GIFs)?

Ditto. Average energy impact is 3.24.

There is no native Slack app. They're all Electron apps. But I think you already knew that.

2 vs 11 is the precise difference that is important. The author shows that things are more reasonable with 2 accounts.

Without seeming to endorse one platform over another, I've personally seen Slack to be a huge memory, cpu and battery hog. Most of the time, I don't have it open and it hugely hinders my response time to my team. But I can't lug around my 64 GB RAM hackintosh to a coffee shop.

6 Teams on my computer: https://pasteboard.co/GCWfKca.png

Edit: Decided to write a little bit more on this.

> How?

The problem is with Electron shell apps. Electron, while it has made it extremely easy to build a webapp and then ship "native" versions of that webapp across Windows, Linux and macOS, the end product is horribly bloated.

Here are 3 Electron shell apps I am running. They're all bloated. I can't run too many of these at the same time. This laptop has 16 GB of RAM. The other Macbook I have has only 8 GB.


- Spotify (music)

- Slack (messaging)

- Dialpad (voip + messaging)

So why is it like that? Electron shell is basically Chromium browser with a much more comprehensive native API that a web browser will allow. The 'Native' UI you're seeing is HTML/CSS and JS.

> Why?

Chromium introduced a very long time ago a process model such that the various subsystems are run in separate processes communicating over IPC. This is very different to a traditional app where you have one process splitting up work over to worker threads.

Chromium used this model to make a solid web browser. Each tab is its own independent process. Each extension is its own process. The rendering work is done in its own process.

Look at the Chrome task manager for example: https://pasteboard.co/GCWmnS9.png

The rationale behind this was that if a webpage caused the browser to crash, it would only crash that one tab and not take down the entire browser. Since processes are isolated into their own virtual memory space, there is much more secure sandbox isolation across processes - so even in the case of a security vulnerability, the process model is fail-safe.

The problem now is that all these processes have a higher overhead. Modern OSes are smart enough to copy-on-write when a process forks (duplicates like a biological cell) - so you're not exactly linearly increasing memory overhead.

Now that these processes are running, they need to communicate with each other. By default, processes are independant and don't share memory across them. So any communication has to be done with IPC(mechanisms for processes to communicate with eachother). This typically happens through Named Pipes, Unix sockets, or even TCP and HTTP. All of this carries more overhead. Running a whole http server to talk just intra-app is absurd and I don't believe any common apps do this. But these types of mechanisms are how these processes talk.

> Solution?

Now back to the concept of the process-model. The isolated process model worked well for browsers. But in the confines of a single app, they don't work well. I would much rather have a single process Electron shell that is able to spawn background threads to do additional work.

Sadly, we're way too far down the other road. I don't know of any effort in Chromium or Electron to retro fit the process model. But if we had one, it would be awesome.

You could also not use Electron shell to build apps. Modern platform frameworks are pretty good. Windows has a XAML + .Net frameworks that is somewhat similar to HTML/CSS/JS. macOS has the fully native Swift and UIKit. Linux...well Linux is good in it's own way too.

But this is really not an option for most start-ups. So don't do that if you're a small company. I would much rather see and use your slow bloated product than to not being able to use it on all platforms.

There's also weird bugs/features. Have an animated emoji in the currently active channel. Just one. Put Slack in the background - it's still using 10%-15% of a 2016 MBP CPU. WTF.

I noticed this a while back too. Switch to a private chat that only contains text when you tab out of a team and it doesn't hog. I think the "don't draw in inactive windows/tabs" feature implemented in most browsers is missing.

Even without the optimisation - I recall seeing animated gifs on older hardware without a huge cost. What is it doing? It's like when Google Play Music takes 20% of my 4-thread 1-2GHz i5. I'm pretty sure I listened to MP3s on a Pentium 166 without it pegging the CPU completely.

(And Google Play on Android... on a Nexus 5, I'll sometimes wait 5+ seconds for the playlist to open after clicking the icon.)

> I'm pretty sure I listened to MP3s on a Pentium 166 without it pegging the CPU completely.

I can collaborate that. I remember upgrading from a 486 to a Pentium 166 and being excited that I could finally play 44khz stereo MP3s at full quality and not be constantly skipping. I could even browse the web at 56k at the same time!

The Slack desktop client implements multiple teams basically the same way Chrome implements multiple tabs. And we all know the rule of thumb: you can create one Chrome tab per gigabyte of memory.

It's remarkable how bloated browsers have become. I remember having multiple Netscape 3.x windows open back in the mid-90s, on a 486 with 32 megabytes of RAM.

Sure, but browsers today are incredibly complex runtime environments that support all kinds of apps. That inevitably results in bloat.

Agreed, but not orders of magnitude more complex. It's not just browsers... all software suffers from this bloat.

Because electron app was built on chromium

Yeah but the authors of the Slack app didn't have to learn anything but Javascript and HTML. What else could be more important than that?

Yes, developers are more important than users.

Previously I ran the Slack desktop app on Windows/Mac/Android and for IRC Hexchat on Windows, Textual on macOS and nothing on Android (I couldn't find a good IRC client). A ZNC instance on the server was keeping these IRC clients in sync.

Using Slack over IRC would have been interesting but then I would lose the rich inline previews of links/media on Windows because Hexchat doesn't have these and I don't know any other standalone IRC client for Windows which has this feature.

Then I switches to IRCCloud and now I use it for both Slack and IRC:

- Better synced state across clients compared to ZNC

- The Chrome tab needs ~600 MB RAM which is less than Slack + extra IRC client

- Unified chat UI across Windows, Mac AND Android :)

- inline previews like Slack

Running my own ZNC instance on a server was not a big hassle but its buffer replays where annoying and depending on the settings it would DOS my IRC clients for several minutes because they where busy processing the incoming buffer backlog.

Haven't seen it posted here yet but wee-slack [0] works wonders if you're not afraid of using weechat.

I'm looking at an average CPU usage of 2% and memory usage of ~30MB for three IRC networks and three different Slack teams.

[0] https://github.com/wee-slack/wee-slack

As someone who works in encoding video at resolutions greater than 8k all day, the only way I can work with Slack is by making use of wee-slack. Every other option is either not complete enough to use, or too expensive on CPU/GPU to justify.

I remember reading somewhere that the source of problem is gifs. They are kept in memory and always running, even if off screen. If this is true, the solution should be pretty easy?

I had this realization some time ago: almost everything I do on my desktop runs in Chromium wrappers: Chrome (duh), Spotify, Slack, WhatsApp, Signal

It's almost as if you could make a whole OS out of Chrome. Someone should look into that. ;)

If only there was a way to write apps that could share an instance of Chromium, and access native resources the way they can with Electron. Oh wait: https://developer.chrome.com/apps/migration

Javacript "apps" on desktop using too much CPU and memory?!?

Say it ain't so!

There's nothing inherently evil about JS in this context that isn't true about Python or Ruby -- it's just that JS's default UI toolkit is horribly bloated.

Perhaps shoehorning a half-baked web scriping language into native app development isn't such a good idea.

Not all ideas are created equal

"Note: I am running a Slack desktop client on OS X with eleven (11) accounts."

Admittedly, Slack is a lot of resource usage for what is something like a glorified IRC client, but this is not the average Slack user.

That's not that outlandish. Many open source projects are using Slack, in addition to commercial projects. I've even seen some unique uses of it (like Airpair used it to bring together mentors and clients). Of course, I only use the Slack app for my main job, and any side projects/open source I use the browser for :-)

Ditto.. but my subjective feeling is that it's getting laggier there also. I mean, it was kinda lightweight back in the days but it's getting less and less responsive.

People will complain all day about Slack, but somehow still use it.

If we are so concerned, why aren't we all moving to Matrix?

The only reason we don't leave slack is because there's 3 years of indexed useful chat history. And the sales guys like it. The rest of us think it's slow and bloated.

Because most Matrix clients are equally ridiculous, and the Matrix protocol is even worse.

sigh - if you are going to badmouth Matrix, please at least disclose that you are doing so from the perspective of working on an alternative standard (IRCv3).

That said, agreed that Riot/Desktop suffers similar problems to Slack thanks to being an Electron app. Pure Qt clients like nheko and quaternion have a lot more promise on the desktop.

In terms of the protocol: yup, the baseline Matrix protocol is plain and simple HTTPS+JSON. Patches welcome from anyone who finds this enough of a problem to provide alternative efficient transports :)

[disclosure; i work on matrix, although grew up on IRC, and respect the IRCv3 project, despite behaviour like this.]

I'm not an official member of the IRCv3 project, and can't speak for them - I only engage in discussions in the IRCv3 WG which affect the client I am working on.

That said, Matrix is a great concept, but, as mentioned, the currently implemented clients and protocol (with HTTP polling with JSON) are very inefficient.

With Quarternion as client, and a raw socket or websocket based protocol using Protobuf or Flatbuffers for serialization Matrix could actually become the fastest and most efficient open chat system.

You have to realize that I'm seeing this as someone who uses clients on 7 year old devices on throttled 2G in daily use, to ensure that they work well enough under any conditions. (And while some IRC clients do work there, any Matrix client is completely unusable under those conditions).

> the Matrix protocol is even worse

Could you please elaborate on this?

I can't speak for kuschku, but the normal complaint is that every message you send in Matrix is a new HTTP hit, and every batch if messages you receive is a new HTTP hit - and this (combined with the message format being JSON) is less bandwidth and roundtrip efficient than a dedicated TCP line protocol like IRC.

And this is true, in the default baseline protocol. It makes it absolutely trivial to send and receice messages; you can just fire up curl to do an http PUT to speak or GET to receive.

However, Matrix does let folks define more efficient optional transports, but in practice (other than a websockets+JSON proposal), nobody has bothered. It seems that for most purposes HTTP+JSON is fine; after all the whole web revolves around it, plus you don't need to worry about timeouts on a single tcp socket etc. And with HTTP/2 most of the concerns go away anyway, as the overhead of new requests is fairly minimal (same socket; header compression; etc).

On mobile devices a better transport would be desirable for reduced battery and bandwidth consumption, and I'm sure we'll eventually see one. But for now HTTP is perfectly serviceable, if not the most efficient solution.

Isn't Slack just another example of what happens when developers want a "cross platform solution" instead of writing a native app?

No, Slack is what happens developers think that HTML/Javascript is a good platform for applications and that shipping a full-blown browser constitutes a native app. Qt is a good cross platform solution if you want cross-platform.

Although, I wonder if Slack is constantly sending and receiving status reports. I'd like to be able to set it to check every 5 min (or even 1 min) and see if that helped things. I don't need to be notified immediately; if they needed that they would call me.

Doesn't really make it better but if you're forced to use Slack their IRC bridge is pretty pleasant to use.

There is a Slack client for Emacs: https://github.com/yuya373/emacs-slack

Slack also has an IRC bridge which you could use with erc or rcirc.

I'm so glad he advocated for IRC. If we can get IRC to have inline images and chat history, we are good to go.

LimeChat on the Mac supports both of those features. I'm sure there are other clients that do as well.

And for history, there are plenty of history bots that have web searchable archives of IRC channels.

Weechat with Glowing Bear does too but it needs to be set up.

IRC already has these, its just a matter of packaging it.

FWIW irccloud is a lot like slack but for IRC, they offer "team" accounts and hosting. No search, though.

and chat history

How is this not possible with IRC? Channel log bots have been around for yonks.

Only Slack's integrated view of history is acceptable to nontechnical users. Also to technical users like me who don't want to mess around maintaining and talking to bots.

I believe the dismal UX in your suggestion is the reason Slack is popular. By contrast, "it just works" and it works consistently across all communities, making for a compelling product.

You can get that with weechat + screen + glowingbear.

Or with an IRC bouncer but we're well beyond what I would expect anyone non-technical to set up.

Textual 6 supports inline images and chat history.

Energy impact isn't a percentage. It doesn't have any units. I understand that the author is trying to prove a point -- and those points are valid, but it's not that Slack is consuming 63% of your energy. It's an arbitrary measure. [0]

> So, in conclusion, on 10.10 and 10.11, the formula used to compute “Energy Impact” is machine model-specific, and includes the following factors: CPU usage, wakeup frequency, quality of service class usage, and disk, GPU, and network activity.

[0]: https://blog.mozilla.org/nnethercote/2015/08/26/what-does-th...

If only browser developers would agree on some standard to "Add web app to desktop". Something similar like Prism extension on Firefox was back in the day, except all apps would run on single browser instance. That should solve "electron problem".

Chrome and other Blink based browsers are doing this on Android already, PWAs can be installed to the device and are treated like a native app. (Except that they still use the web's more restrictive permissions model)

I think WebAssembly that basically draws to a bunch of pixels is the prerequisite. Then we create a decent UI library (NOT html).

Can somebody tell me why a chat application should use 5% of a CPU and over 100MB per account?

Well, to be fair, it is much more than just a "chat application". It's now voice, screen sharing, etc.

They've built a lot of features with chat being at the core.

But why should any of those features consume system resources when they're not being actively used?

At this valuation I would start shooting for writing native clients at this point. They even have an iOS client that has done half of the work for them at this point on OSX.

Most people are upset with slack due to memory usage. I get that a chat app shouldn't use so much ram. But then there was a time even a browser wouldn't. This is how software has always grown. Windows XP minimum ram 64M, windows 7 wants minimum 1G. But we are all fine with it because the hardware has also grown. So to those who have a problem with slacks memory usage ask yourself: why are you using a machine with less than 32G of ram?

Comparing an OS and a chat client, really? Very wide conflation.

I'm fine with things using a bit more resources, but not three or four orders of magnitute compared to 10-15 years ago.

It's all about quick time to market, various Electron-based "desktop app" maintaners have openly admitted it right here in HN (though not in this thread). Any technical disagreements were killed off with (1) we won't hire developers who are specialists in desktop development due to costs and (2) our app doesn't use that much resources, everybody has strong machines nowadays anyway.

So it's okay for a chat app to be a resource hog for no other reason than developers that are incompetent and "we have lots of ram today"?

Cgroups: limit memory, limit CPU, and voila - it works! Slack is one of the resource hogs that will take all that you'll give it.

could you post some examples of limiting slack with cgroups?

After some failed attempts, I gave up, copy-pasted and mangled what Sam Thursfield made for Firefox, substituting Slack where applicable and uncommenting the CPU quota: https://samthursfield.wordpress.com/2015/05/07/running-firef...

See "How do I use cgroups ?" in the kernel docs: https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.t...

You can do it simply by mounting the cgroup fs and writing numbers to files.

Seems like there should be a better solution than making every slack user read that document.

Sure, but sometimes we have to wrestle with shitty software. There's a scanning tool we use that unrestrained will consume all system resources, lock up all the useful software, and occasionally crash severs.

Set up a cgroup with a quota and problem solved.

Worked first try, with no problems! Thank you, really great solution!

Is Slack well-behaved when it runs out of memory? Or does it just crash?

It crashes but recovers. IMNSHO a less broken solution than an instant messenger that absolutely needs all the system resources for itself.

The answer: Electron and this new breed of lazy "developers" who can't be bothered to actually make decent native apps.

Given that Visual Studio Code is also built on Electron but poses none of the resource issues (in spite of being a much more complex application - ide v/s chat client), makes me think the problem lies with the application and not the platform

I like VS Code. However, people think it's "light" and "snappy" only because they're comparing it to Atom. IntelliJ feels pretty fast-loading and snappy when you put it head to head against Atom.

The reality is that Code takes multiple seconds to launch on my machine (a MacBook Pro with 16GB RAM), while GVim or Sublime or any native editor is subsecond. Granted, it does perform well enough once it's up and running. But startup time is probably an order of magnitude worse, and ongoing resource consumption even far less competitive.

Code shows that it's possible for a good Electron app to be better than a bad Electron app. But that's not a proof statement that Electron is in the same league is native.

> people think it's "light" and "snappy" only because they're comparing it to Atom

There's some truth to this, but I also prefer it to (my previous workhorse) Sublime. Which is a 100% native app, unlike Atom.

> The reality is that Code takes multiple seconds to launch on my machine (a MacBook Pro with 16GB RAM)

Something is wrong there, it really shouldn't. 1 second, maybe, if you're loading a large complex folder or something but unless you've got a crap ton of extensions I've never seen it be that slow.

And aren't most extensions lazy loaded anyway?

No idea but that would make sense.

Yes but they probably worked their arses off and spent big bucks to get it to perform. And it's kind of a marketing product: one of Microsoft's catch-up-with-whats-hip initiatives. For the average shop just code native and get that performance for free.

It poses its own resource issues.


Please don't blame Electron. VS Code is an Electron-based application and it runs beautifully, with much less RAM/CPU hoarding than Slack.

I only run Slack in a Chrome tab now.

I feel like it's still right to blame Electron - it coerces developers into being lazy as it stops them from having to actually think about how their apps behave and what resources they consume. Not to mention that it encourages platform-hostile user interface design in the name of "portability".

Damnit, HTML and JavaScript were never meant for this kind of abuse.

the users needs should be prioritized over the "platform" while I agree with the overall message here... I hate hate hate how my MacBook "Pro" regularly hits the 8gb limit. Very obnoxious

By prioritising the platform, you also prioritise the user. As a macOS user, I am happy with how the average macOS application behaves and looks and feels and I feel like application developers should respect that.

Same for someone writing a UWP application for Windows 10, or an Android app. You don't win by degrading the experience on all of your target platforms because it's "easier", you win by carefully considering the people who actually will be using your software and the circumstances under which your application will run.

Not really... it's still considerably slower than Sublime, Gedit/Pluma (or anything gtksourceview), vim, and others, and VS Code got to where it is today due to much gnashing of teeth

I would love to see Electron abandoned...

> it's still considerably slower than Sublime

This does not match my experience. Sublime + Plugins to bring it to parity with VSCode === much slower than VSCode. Especially with larger files.

Wouldn't know, I don't use plugins. I would imagine that to be the case though, given that it's extra code from third parties. Similar slowdown is common in nearly all plugin systems.

Oh true. That's an issue for sure. That said - I value the extra bits that VSCode has over Sublime out of the box. Some may not.

What alternative would you propose?

I haven't played with QT's JS backend but that looks nice. (It's C++ native)

pyGTK is a good toolkit.

On the JVM side of things there's JavaFX

Almost anything is better than bundling webkit really... even WinForms. And the above list is mostly new stuff for new devs. For the real programmers amongst us there's QT, GTK, JVM's Swing...

Do you have an example app in production that cross compiles to all platforms? Also, what constitutes a real programmer?

> Also, what constitutes a real programmer?

People that aren't afraid of the hard stuff, and don't need software to wipe their ass?

As for software... IntelliJ IDEA (Swing), we use internal pyGTK stuff that runs on Win/Mac/Lin, Wireshark (QT), Mozilla Firefox (XUL ... another brilliant UI markup language which died for no good reason), pgAdmin III (wxWidgets)

On the music plugin side of things there is a lot of VSTs written in JUCE framework, another good cross-platform UI kit which focused on audio software.

People that aren't afraid of the hard stuff, and don't need software to wipe their ass?

Exactly the sort of shitty attitude that will get us nowhere.

I have seen a plethora of QT, GTK and other cross-platform applications that weren't only laggy as shit, but riddled with UI bugs.

I fucking hate that Electron is now an accepted way to build applications, believe me – but the reason we ended up in this situation is because "real programmers" failed to develop a framework that effectively dealt with developer and user needs.

Well its the only attitude that is left after one's opinions and practices are continuously railroaded by excess industry profiteering and need for "change". Sure, nobody stands up to defend the bad attitude but how can one have anything else when all you see are perfectly good things thrown away because they're not shiny enough? I'm sick of watching this field serve shit for dinner and I have no problem with making people feel bad for their bad decisions. Don't want to get made fun of? Don't do things worthy of being made fun of. (The peanut gallery is always watching.)

Anyways, it shouldn't be the job of the toolset to prevent bad users from shooting themselves, therefore you are always going to have bad, laggy programs in any UI paradigm. It is the job of the toolset, and those that built it, to not take any one piece of tech too far (in this case, HTML rendering engines) when there are so many acceptable and superior substitutes.

Damn. I better change my info online and stop people I'm a programmer. Better notify all sorts of census and demographic departments. We have been over accounting programmers in the tens of millions, if not hundreds of millions!

> On the music plugin side of things there is a lot of VSTs written in JUCE framework, another good cross-platform UI kit which focused on audio software.

Real audio programmer here.

I used nw.js (essentially like Electron without the necessity to do IPC for intra-window communication) to port the frontend for a realtime audio engine written in C. Frontend and business logic speak over a socket.

No need for JUCE because the UI has no need for JUCE's audio tools.

Port could happen extremely fast because of the brilliance of Chromium devtools-- introspection and real time updating of styles/DOM state was a life saver. This was a port from tcl/tk which had (has?) a half-baked theme-ing engine and no easy way to introspect the contents of a Tk Canvas.

Qt would have been nice but the frontend is a visual diagram with boxes connected by Bezier curves. QML doesn't have an easy way to do that without the performance scaling with the size of the logical canvas (which is unacceptable because users sometimes want enormous logical canvas sizes).

What if someone told you that using Swing, QT, and GTK were all bad, rsource-wasting things made for people that "need software to wipe their ass", and that "real programmers" use butterflies? Check this out to better understand the "no true scottsman" fallacy: https://www.xkcd.com/378/

You're just hating on something new and praising some old things, but in the past, those same things were also hated on for the same reasons (e.g. so many people hated on swing and java in general early on for wasting memory; "real programmers don't use Java")

Each electron app spawning up separate instances of chrome is totally wasting memory. Argue about that, instead of "real programmer" bs

What a novel concept! I feel so edumacated now. Surely my IQ rose by a few points.

And to follow-up edit, of course theres no one true scotsman. The assembly-reciting graybeards look down at GUI programmers, who look down on the webdevs, who really don't have anyone to look down upon because they still have so much to learn.

And why does the argument always have to be about resource consumption? Does anybody actually even truly care? I hate Electron because it is an incredibly poor use of existing resources and that it leverages tools very inappropriate for the task of creating cross-platform GUI applications. Entire industries are built out of this unholy Frankenstein of duct tape and chicken wire. Now, for the job of quickly banging out an app so the business fucks can make their $$$$$.... now that's different

it is an incredibly poor use of existing resources and that it leverages tools very inappropriate for the task of creating cross-platform GUI applications

… because there aren't better tools.

There are, people just have to step outside their comfort zone to use them.

No. There aren't. There are no good cross-platform development environments. There are a handful which might be acceptable for some user-cases; Electron is unfortunately one of them.

If you think there are a plethora of amazing tools out there that people are using to build cross-platform apps, then you're wrong.

Ok great! Expand on what spedifically makes it less appropriate and what makes alternatives more appropriate.

Qt is C++ native, but if you start using JS you pull in WebKit (or Chrominum, not sure) again, just like Electron. JS and native performance are mutually exclusive.


XUL 2.0? One can dream :/

NativeScript actually looks really cool. It seems mobile only right now though.

> VS Code is an Electron-based application and it runs beautifully, with much less RAM/CPU hoarding than Slack.

Except for that time when it was constantly using 13% CPU to display the blinking cursor: https://github.com/Microsoft/vscode/issues/22900

To be clear, that was a bug with chrome: https://news.ycombinator.com/item?id=13941293

personally I never had problems with discord (also made with electron), seems to me that you can make good and bad design decisions regardless of the stack you use. Don't think electron is alone on this. Choosing a stack makes some things easier and other things harder to accomplish though.

Discord performs pretty badly to be honest. I have it idling with no chats open and using as much resources as other chat clients with 50+ chats open.

Are you in any guilds at all? If yes, it's handling all of them in the background, which would explain at least some of it.

Are you using the Desktop client or the app through your browser? The client is more performant than through the webpage.

That is just silly, blaming the instrument rather than implementation. Electron is an excellent instrument, and you can leak memory and abuse CPU in any language.

Some instruments are more prone on average to do so than others. Why are most flash games horrible on CPU usage but something made in pygame not nearly as much?

Ah yes, all those great games made in pygame like...?

It can be actually pretty subtle since they tend to present themselves as standalone executable games and don't advertise the fact they used pygame, and this was the time before unity was much of anything. Nowadays everyone just uses unity.

One game I remember was a 2D space game that had pretty good graphics, digging into it's folders and being surprised at seeing pygame and python everywhere. But it's probably been 10 years since I've played it so I can't remember the name. The rest is google.

Exactly. It's just bad engineering. Taking shortcuts to save money and not paying attention to important non-functional requirements.

I wouldn't blame this on engineers -- they aren't necessarily the ones making the (albeit very attractive) business decision to use one codebase for multiple platforms.

He didn't really blame the engineers. He blamed the engineering. Unless you were just saying your statement and not implying he blamed engineers.

nailed it

This seems like an ad hominem attack based on developers making trade offs. Electron essentially seems to be born out of the trade off of engineering a web product and satisfying customer demands for a desktop app.

Edit: Removed commentary about most desktop apps based on https://news.ycombinator.com/item?id=14869864

> reliable cross platform experience

In my own personal experience, these applications have almost never provided me with a more pleasant experience than eg a Qt application.

Plus I've had Slack's CSS mess up giving me a weird messed up UI. This has NEVER happened with an actually native application. I've also had Slack consume 4 gigs of RAM, which is ridiculous for something that is never the main thing I use my computer for.

Quicker time to market perhaps, but "reliable cross platform experience".. not in my opinion, at least, unless you mean that its reliably equally bad on all platforms ;-)

EDIT: Cross platform is easy when you don't need a platform-native look and feel, which web-as-native often doesn't do anyway (or not perfectly at least)

Yeah, that makes a lot of sense. Do you feel the same way about rich web apps?

Yeah, in comparison to native apps anyway. At least they don't pretend to be native. But really, I think it depends on use case: most web apps I use aren't things that I need to leave open all day, while Slack is.

Most? That sounds wrong to me, but I don't even know how you're counting.

Most by number of apps? Consider all little enterprise things built in Java or whatever.

Most by time spent? Browsers, AAA games and file managers aren't web apps, surely?

Most by HN hype and VC funding?

Fair. I was considering my own usage where I have very few desktop applications and tend to prefer web products. Apologies for the overstatement.

This is a very short-sighted comment.

Electron or not, you need a web browser to display content. Unless you want to replicate a browser's layout engine, poorly. History and the rich interface are the main appeals of Slack.

I guess you could create a QT app or something and embed a web widget inside. Not sure how much that would help.

I might be confused. I thought Slack was a text chat client with extra features. Why does it need a browser engine for layout, instead of using the system's native layout tools like native software has always done?

It is a text chat client. However, it does not display only text. It can also display images and whatever else can be displayed by a web browser, including links and buttons.

You can replicate it with native widgets. Heck, you can draw everything yourself if you want. But why bother, if you already have a perfectly good way to display that sort of content?

The problem is not "lazy developers using Electron". The problem may actually be lazy developers, but not because of Electron alone.

If what you want to display is a subset of what web tech can display, it's lazy to embed a big web engine.

To me it's like sending a word doc attachment because you want to use bold type in a mail, and you already know how to use word.

Do I actually need to display web content? Unless I need some custom embeds which supply their own HTML and CSS, I don't, and I'm happy to do away with embeds and stuff if this means my client no longer makes my laptop go on fire.

Since when you need a web browser to display content?

Slack could easily use native widgets, without embedding any HTML.

Have you used Slack? The rich interface is one of the main reasons people use it. It's not IRC.

Yes I have, and I have used interfaces which were as rich, or even richer, for decades, without the need of embedding web content.

For instance GTK apps in the earlies 2000s were easily displaying content as rich.

I understand that. But we also have apps like Adium displaying their chat messages using HTML with no issues, just because they want to easily customize the themes.

Point is, native or not native, this should not matter for a well optimized code. We are not talking about a AAA game here, it's just a chat app. It should not be burning cycles when inactive.

I feel like I've made a mistake mentioning IRC - that was just an example to say that a client that receives and sends messages over the network was a solved problem.

Rich interface doesn't mean HTML and CSS. Have you seen good iOS apps? Their interface is just as rich and yet it's pure Swift/Objective-C compiled down to native code.

There are plenty of chat apps with rich interfaces not implemented in HTML. Some of them far better than Slack.

Can you provide some examples?

Messages on OS X?

I know right. Real "developers" only write in assembly with a completely separate codebase for each target platform. No code review or source control either, because they're not lazy.

Actual issues aside (yes slack takes up way too much memory and it's due to the platform they chose which is hugely bloaty but will undoubtedly get smaller/faster over time just as everything does) why would you choose to attack the developers for building a tool that millions of people use with great success? They're not lazy. They used the best tools available to them to deliver their product and they're reaching the limits of said tools. Now they have to address those limits. This is exactly how software is supposed to work.

I choose to attack those developers because they're taking an easy path knowing that it will end up in a bad product, yet they still do it.

At the end of the day I don't care which technology is used as long as the end product is good, however a chat client that uses 1,5GB of memory is the total opposite of good. Come on, it's a f'ing chat client - a solved problem and existing implementations (look at any IRC client) take like 100MB's max. I would have no problems with Electron if they somehow managed to get the resource usage similar to a native app.

Perhaps the attitude of measuring the good-ness of a chat client solely on how much memory it uses is one of the main contributors to the rise in popularity of Slack and the decline in popularity of IRC. I personally don't care if my chat client uses more ram than its competitors if it's easier to use. Judging by the amount of people using Slack, I don't think I'm alone.

If its a "solved problem" then why aren't users flocking to IRC over Slack?

The answer is likely multifaceted, but part of it is undoubtedly the usability of the client - which may be resource intensive, but that was likely a trade off for speed/ease of development.

Why would people flock from Slack to IRC? IRC is much older, it's probably more like people sticking with IRC and not trying Slack. Which presumably is happening in large numbers.

NIH Syndrome. You can't make a walled garden out of IRC.

Why can't you? You just don't connect your IRC server to any other server.

True, so maybe they're also hoping for patents or other ancillary NIH benefit.

Marketing? IRC's not sexy like Slack is. Realistically, it's going to take what, 10 extra minutes for a dev to get IRC down versus Slack?

There's an important realisation as a developer, or in fact as anyone whose work affects other people. Consider a bug or badly created feature that costs users ten seconds of their time. Let's assume a hundred thousand users, encountering that once a day, for a year. That's 4200 man-hours lost per year.

Is it user-focused to allow that bug to remain? How do you judge the importance of your users' time?

Slack - often Electron-based apps in general - are fast for the developers to create, but cause problems for the users. There are many more users than developers, and a good question is, is the value of users' time and money less than the developers, or the user's resources (such as memory) the developers' to freely use? Developers can't write their whole app in assembly, but at what point do the problems their choice of technology cause for users overbalance a reasonable standard of consideration for their users and user experience? An app with the problems Slack has is one that has largely prioritised the developer's time and resources over their users.

So your "real developers" comment is a straw man ;) But you're close, I think: better is to consider the balance of value developers ascribe to themselves vs their users and what use of Electron, and app behaviour like this, says.

This is literally the same argument people were making when the JVM came out.

But is it a true argument or a false argument? That's what matters.

What matters is that it's an argument against progress. It's an argument of good vs perfect.

Shouldn't this trade off be born by the market? If Electron is such a problem for Slack, users should be switching away to better engineered alternatives.

Just because Slack is useful enough people use it, doesn't meant the tradeoff they've made when developing indicates a high regard for their users' machines or experience.

That's fair. I wonder if users actually care in practice.

The other side to the market question is that this tradeoff may be why they're big in the market - because it allowed them to get to market quickly. So they made the trade-off knowingly, and for a reason that makes sense.

The question then becomes, once established, do they improve the app?

Yeah, I think that's a key question as well.

I'm seeing lots of people around me just giving up on Slack and switching to Telegram. It's not a shining example of good engineering, but it's still noticeably leaner and faster.

I haven't used Telegram in a professional setting but seems like a good solution. I'm hoping Matrix/Riot takes off and the open protocol enables a native experience.

Can you give me some examples of platforms whose memory usage has meaningfully gone down over time?

Nope, but memory usage has increased in sync with how technology evolved - software that used to take X MB of memory now takes X*2 but at the same time your laptop now comes with 2x or 4x the memory it used to.

However Electron takes this to a new extreme - the memory usage of an Electron app is like 15x of that of a native app, and yet I can't buy a Macbook with 100GB of RAM.

Its not even the RAM that annoys me the most about Electron - its the hit to the battery life.

I wonder what I'm doing differently (or if it's my hardware) because I don't notice it consuming much, and it pales compared to resource hogs I run in my day-to-day. Maybe they develop on Macs and runs better on them?

Here's my specs if anyone is curious: 3 yr old MBP 2.3 GHz i7 16 GB RAM

Turning off animations in the preferences (it's under "Accessibility") has done wonders to the energy impact / CPU usage of the Mac Slack client. Much more tolerable now.

I am _more_ than happy to not see animated party parrots in exchange for less CPU.

Maybe use Slack in browser?

While I have not tried the electron version, I feel that my seven slack tabs slow down my firefox noticeably. Especially during startup and after connectivity issues.

While the mobile app is at least responsive on Android, I have problems, too, for example with messages from push notifications that don't show up when opening them.

Subjectively, Slack performed great in the early days but has gotten worse over time.

Tried that, doesn't help a whole lot (the desktop app is a glorified Webkit wrapper).

But it's chromium serving local content. That is somewhat of a difference.

I run Slack only in Safari. It works significantly better than the desktop app.

I don't think serving local content would explain why the desktop app insists on munching through all the available RAM (on a single team, no less!), something else must be going on. But that's actually a pretty good suggestion - I'll try the web version, thanks.

Used to be some time ago when downloads were ~5-7mb. Nowadays it uses Electron:

/Applications/Slack.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework

Yup. A glorified webkit wrapper.

CTRL R works in the "native" app.

Why don't you guys use rambox? It basically loads slack's web interface in the client. And it supports a plethora of instant messaging services. Never had any issue with performance.

I had never heard of this. Interesting. It looks as though this is built on Electron too.

> I love Slack and have no plans to stop using it to communicate with my team at Ably.

As long as your willing to tolerate it don't expect anything to change. If people stopped using slack then the bean counters would sit up and take notice. If slack died it might even serve as a warning to others.

It's easy to blame slack, but everyone that continues to use this and other bloated apps are also part of the problem.

On my desktop, Slack's footprint looks pretty similar to Atom's, hardly shocking given they're both Electron apps. Its 4 pids aren't using much CPU (less than 1% each), and about 800MB of RAM combined. Sure, that's kind of ridiculous for what it's doing, but it's about 1/20th of my total resources or less...

The latest version of slack BETA solves the CPU issues on OSX. I have been using it and its _so much better_.

I'm on Slack beta as well. I have nine Slack groups, with some of them having thousands of users. It's still a CPU hog.

Sounds ridiculous that a chat app can consume that much.

Could we maybe use a terminal client? Seen this : https://github.com/evanyeung/terminal-slack but I cannot build it. Anyone else tried it?

Slack has an IRC bridge that works incredibly well. I have used it daily on past projects. Load up your favorite terminal IRC client and go at it.

How would this work when a team member attempts to screen share or video/audio call?

That rarely/never happens to me. I use it for chat 95% of the time, the other 5% might be someone posting a gist or quoting some code. So for my use, a terminal client is more than enough.

What's it doing in there? Refreshing the screen on every frame, like a video game?

I always try to run a web version of this stuff. Web music player, web Slack, etc. Don't need more garbage on my machine, and since it's essentially a bundle of Chrome, it's good enough to just use it in the browser - where it belongs.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact