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.
285 comments
[ 3.4 ms ] story [ 267 ms ] threadI 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.
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.
https://news.ycombinator.com/item?id=13940014
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.
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.
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.
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.
#spyware #bloatware #adsware
I don't see how any sane software dev / engineer could like this.
(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!
They've built a lot of features with chat being at the core.
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.
Say it ain't so!
Not all ideas are created equal
Of course Apple deserves equal blame for selling machines with limited RAM.
http://matrix.org/
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.
> 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.
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.
http://imgur.com/a/9GpeY
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.
Here's my specs if anyone is curious: 3 yr old MBP 2.3 GHz i7 16 GB RAM