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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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 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.
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 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.
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.
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
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.
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.
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 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...
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.
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
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.
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).
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.
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.
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.
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.
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.
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, 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.
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?
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.
Slack might have 1.5 GB mapped between all of its processes but probably most of the processes many of the same pages, so it's a bit misleading to say Slack uses up 1.5 GB of "real" memory.
Exactly this. The "Memory" tab in activity monitor is next to useless. It doesn't give you any idea how much of that memory is shared, exclusive to the processes, paged out, etc. Each of those processes is using some fraction of the amount displayed in the 'Memory' column.
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.
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 :-)
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 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.
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.
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.
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.
Why the hell does Slack need 800 MB Ram?
I have just created an empty account, empty project, 0 team members (other than me). What the hell are you doing?
#spyware #bloatware #adsware
I don't see how any sane software dev / engineer could like this.
It does read somewhat like an advertisement, seeing that it's just four paragraphs (of which one is a tl;dr and one is not relevant to the title) and four pictures followed by an ad for Ably.
Just to confirm, we are not in any way a competitor to Slack, we are a realtime data delivery platform. The article confirms we use Slack ourselves. See www.ably.io/platform for more info.
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!
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
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.
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?
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.
Does Matrix let me see Slack channels for existing projects? If Matrix can replace Slack, I'd consider using it for new projects. But if not, that just means running both apps.
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.
one of the big things in matrix is the existence of bridges as a first class citizen. matrix-appservice-slack exists today (and riot.im hosts an instance of it; you can get at it via Manage Integrations in Riot). The catch is that right now it needs to have outgoing/incoming webhooks provisioned on the Slack channel being bridged. We are working on fixing this with a puppeting bridge though - and there are a few other projects like matrix-puppet-slack which also aim to do this already. https://matrix.org/blog/2017/03/11/how-do-i-bridge-thee-let-... has the gory details.
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.
Please don't troll and have a look at what Ably actually is.
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.
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.
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 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
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 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
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
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.
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.
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...
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.
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.
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
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.
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.
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.
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.
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.
> 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.
> 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.
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.
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.
> 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.
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.
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.
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).
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.
We have digital assistants that can match photos by time+location+people and create complex results, why OSes don't have (natively) elaborated and user friendly alerts/solutions when apps do detrimental stuff like that?
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).
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.
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.
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.
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.
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.
> 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.
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.
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?
Yea, I usually browse in Firefox and keep the Slack desktop app open, but when I'm on battery for more than a few minutes I'll kill both and switch to Safari with the Slack web app opened in a tab. That practically doubles my battery life.
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.
> 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.
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 am getting really fed up with Slack and other CEF/Electron apps. Between Slack, Spotify, Atom, Adobe CC, and Firefox (the one program that isn't running on Chromium), I have no RAM left.
Why does Spotify use 1 GB of RAM, and 1 GB of swap?
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.
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.
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.
That is not at all how to use Circa. Don't try to sound smart using words you don't understand.
>Circa is widely used in genealogy and historical writing when the dates of events are not accurately known. When used in date ranges, circa is applied before each approximate date, while dates without circa immediately preceding them are generally assumed to be known with certainty. Circa should only be used for dates that have occurred in the past
reply