Where’s all my CPU and memory gone? The answer: Slack
medium.com
medium.com
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.
Doom and Half life were at their core exceptionally optimized C.
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.
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.
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.
Most of the web is a usability nightmare.
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.
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...
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.
"Memory is cheap, development time is expensive"
and:
"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.
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.
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.
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.
Have you looked at discord's homepage, they specifically say its "Free Voice and Text Chat for Gamers"
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;
Inferior to what and by whose standards? Itanium?
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
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.
Running it on Edge is significantly better on battery life and it feels snappier.
I agree 100%. But it is still my preferred messaging platform, much better than Skype for Business, lync, anything else I have used.
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.
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 rarely have more than 10 Chrome tabs open. How many Slack teams do you have open? Do you have the latest client?
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.
Props to Facebook for mandating low-bandwidth testing
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.
Originally made for mattermost, but I'm adding slack support (currently in master and only basic).
Not sure why so many people use the desktop app. It's an Electron app so of course it will suck up everything.
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.
And its just running as a tray icon.
It seems they are trying to hide what they actually use.
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).
> 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 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.
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.
[1] https://slack.engineering/reducing-slacks-memory-footprint-4...
Quotes:
>> 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.
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.
Windows 10 memory compression saves them a lot, but this is absurd, chrome/outlook use roughly 30% of this.
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.
https://pasteboard.co/GCWiqSB.png
- 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.
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.
(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 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!
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.
I'm looking at an average CPU usage of 2% and memory usage of ~30MB for three IRC networks and three different Slack teams.
Say it ain't so!
Not all ideas are created equal
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.
If we are so concerned, why aren't we all moving to Matrix?
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.]
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).
Could you please elaborate on this?
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.
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.
How is this not possible with IRC? Channel log bots have been around for yonks.
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.
FWIW irccloud is a lot like slack but for IRC, they offer "team" accounts and hosting. No search, though.
And for history, there are plenty of history bots that have web searchable archives of IRC channels.
> 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...
They've built a lot of features with chat being at the core.
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.
You can do it simply by mounting the cgroup fs and writing numbers to files.
Set up a cgroup with a quota and problem solved.
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.
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.
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.
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.
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.
The question then becomes, once established, do they improve the app?
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.
Slack could easily use native widgets, without embedding any HTML.
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.
For instance GTK apps in the earlies 2000s were easily displaying content as rich.
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.
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.
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.
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.
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.
I only run Slack in a Chrome tab now.
I would love to see Electron abandoned...
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...
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.
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
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
… because there aren't better tools.
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.
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).
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.
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.
This does not match my experience. Sublime + Plugins to bring it to parity with VSCode === much slower than VSCode. Especially with larger files.
Damnit, HTML and JavaScript were never meant for this kind of abuse.
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.
Except for that time when it was constantly using 13% CPU to display the blinking cursor: https://github.com/Microsoft/vscode/issues/22900
Edit: Removed commentary about most desktop apps based on https://news.ycombinator.com/item?id=14869864
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)
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?
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.
Here's my specs if anyone is curious: 3 yr old MBP 2.3 GHz i7 16 GB RAM
I am _more_ than happy to not see animated party parrots in exchange for less CPU.
I run Slack only in Safari. It works significantly better than the desktop app.
/Applications/Slack.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework
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.
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.
Could we maybe use a terminal client? Seen this : https://github.com/evanyeung/terminal-slack but I cannot build it. Anyone else tried it?
Why does Spotify use 1 GB of RAM, and 1 GB of swap?
> Co-founder of Ably: Simply better realtime messaging.
oh...
Different kind of messaging.
Slack is for one human to message another human, not for one application to message another application.
He's completely right about Slack though. This is just one of many reasons I tend to hate non-native apps.
And this isn't the first time I've heard of this issue with Slack (by a long shot).
If this post does anything to get people to care about performance and memory usage or the Slack people to work to fix this... fine with me.
It's data messaging, not user / VoIP / chat messaging. We are in no way a competitor to Slack or ever will be. We deliver a platform realtime data delivery. In fact, companies like Slack are often our customers.
See https://www.ably.io/platform if you want to see what we offer and how it is in no way related.
A single app with one purpose should all run in-process and use threads to schedule work.
Of course Apple deserves equal blame for selling machines with limited RAM.
I, and many people I work with, already have Slack running for other projects. Often projects where I didn't get to choose the system.
We can blame Slack in this conversation but I think an equally interesting discussion resides on the OS side, who can avoid not only Slack to be so detrimental.
I think UX sometimes get too much attention on the flashy/entertainment side and performance/speed is overlooked (look the state of websites).