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.
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.
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.
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.
I really can't understand why Slack doesn't just go with a native app (to address performance issues on Electron).
They're a big enough company to work on developing platform-specific apps which would totally improve the user experience (from a performance standpoint at least).
Slack is a poorly-written Electron app, and unfortunately it's the poster child for it.
Discord does more with a fraction of the resources, and is also Electron. Atom is a giant editor framework, and is still less heavy than Slack in normal use.
Electron can run quite reasonably when you aren't an idiot/under complex enterprise requirements which probably explains Slack's load.
Slack uses ~ 2 GB of Ram and ~ 10% CPU when idle. I used it for a short while but now I'm just leaving a Slack tab open in my browser. Its exactly the same functionality-wise.
Basically I'm fine with Electron apps but I have yet to find one that I need and can't be replaced by a browser tab.
Slack on macOS is Electron. Slack on iOS is native, and their app wasn't actually all that bad until they redesigned it a couple months ago and made it really, really bad :(
Have you noticed Slack slow down/use too many resources as a result of being an Electron app? Honest question, I've never used Slack, but have used other Electron apps and never really have any issues.
Unfortunately, I’m in a place where I can test your argument, so the best evidence I can give you is the personal anecdote that I run Slack in Safari rather than using the Electron app for performance reasons. It’s not quite WKWebView, but I think it’s a relatively decent approximation. With that said, I still think you’re missing the point: it’s completely possible to make a messaging app that uses significantly less memory than Slack does and does basically the same things, even if you ditch native controls (which is not something I prefer people do, for reasons other than performance, but it’s something I am willing to tolerate). Loading an entire browser with its associated baggage rather than using the platform’s native web view will almost always use more resources, because you will have bloat that is not necessary for what you are doing and some features will end up being reimplemented in Electron. Just because Slack might perform poorly in both a web view and Electron (which I still believe is not equally poorly), does not mean that it could not perform well at all. There are multiple issues here.
I don't like Slack for that reason, but it's a Slack issue, not Electron. Other Electron apps (vscode, keeweb for example) aren't that resource hungry.
It still amazes me that Slack, with its infinite resources, hasn’t built native clients. One code base is nice and all, but man I loathe the Electron app.
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.
reply