It's still 100% an improvement over what we used for chat before (Skype), but I'd be much happier running IRC or XMPP hosted on one of our servers. The boss decided on Slack instead as it's less maintenance on my part. I don't mind the extra work involved with running something we control, but the company wants me on other projects.
The only solution on Linux that implements audio, video and screen sharing is Sky (http://tel.red/), and it's incredibly flaky.
It doesn't help that the client hasn't had much more than cosmetic changes in at least five years, and is largely abandoned for Microsoft's kludgey Slack competitor.
When something bad happens, usually it is network infrastructure related or some IT experiment going on.
Sometimes when trying to log in it would say that the (saved) password was incorrect, the user would go change it in their Microsoft account and it still wouldn't take it, then a few hours later it was working fine again.
Slack also has much better search, and their support for attachments is dead-simple. Sending a file on Skype was always a chore that felt like it was 1999 all over again, but on Slack it's literally drag, drop, and collaborate.
As I said before, Slack wasn't my first choice but it's a good platform for what it is. I don't like that our conversations and files are stored on their servers, but I doubt anyone at the company is sifting through our stuff looking for dirt or valuable info on a small business with 10 employees.
On X, this means emacs-slack displays images, emoji &c. just like the web or pseudo-native clients do.
If it's so hard to write native macOS, Windows, gtk+ or Qt apps — maybe that's a fault of those development environments. Granted, 'display sequences of text, optionally with some images' is kinda in emacs's wheelhouse.
But seriously, how hard would it be for a sneaky dev to make emacs with emacs-slack into a normal person application with clicky buttons and no ugly gnu? Could be worth a lot of money, or at least github stars.
Well, out of the box emacs has a clicky-button toolbar: https://i.stack.imgur.com/ml0UE.png
And using the keybindings folks expect from Windows is part of modern emacs: https://www.emacswiki.org/emacs/CuaMode
As an aside, I absolutely love the idea of every new app being written atop emacs, but I'm an incorrigible emacs user. I use emacs for email, for git, for slack and (often but not always) for web browsing. Oh, and also to edit text.
Standalone client and its helpers are sitting on ~800MB committed on my install of High Sierra. Might be worth a shot.
A big part of why this occurs is Electron. Same with any app that's basically a browser app: memory usage is out of control relative to what the application does.
Case in point: https://arcade.ly/games/starcastle/ (disclaimer: I wrote this). Uses 284MB, for a version of a vector arcade game from 1980. Same issue with my version of Asteroids too: https://arcade.ly/games/asteroids/. Some of this is down to the idiotic way the Web Audio API handles compressed audio, but with Asteroids I have to pre-render a lot of images because canvas 2D performance isn't that great with drawing primitives. Even excluding these issues, and allowing for several canvas layers at 1366 x 768 x 32 bits per pixel, double-buffered, and the thing still seems to consume quite a bit of RAM.
Welcome to the wonderful world of JS/CSS/HTML5 apps.
RAM prices have plateaued due to production shortages in the past few years, and many (high-volume) $200 laptops/Chromebooks do not come with 8GB of RAM.
To put this in perspective, I was talking this week to a developer who was essentially apologising to me for a new feature that was going to require insane amounts of memory. This is for a process to handle literally millions of users.
How much memory was it? 3G. Per "instance" of which we need 2... Again, for millions of people.
I think "team software engineering" plays a big part of this, if not even the main reason. When one developer is working on a program, the person tends to be able to keep track of program flow, memory usage in their head and know when things are about to go out of bound, memory shoots up, etc. When you have a whole team working on a huge piece of software, each person is working on one part of it at a time. If your feature grows memory usage by 100mb, it's not a big deal. 20 people doing that, memory usage just grew by 2gb. And then in modern software dev shops, you typically put devs on different features on a weekly basis. (unlike traditional, slow, non-agile development where a person owns a certain module/component and is the expert and works on it for years) When you move to a new feature, you need to pick up on all the details of how it works previously, and you build your stuff on top of it. You don't have context of the really nitty gritty details someone who wrote the original framework thought about. You're going to do something less than ideally efficient. Unfortunately, this is just the way modern team software engineering goes.
Or of course, you can still just say it's a Javascript problem and mock JS; which also has merits.
Then don't freaking do that. There's no reason to make one huge app with thousands of features that justifies teams of dozens of devs instead of tools that do just one thing (and can be used in a modular way) correctly and nothing more.
Actually, there's one terrible reason: the bigger the app, the higher the wall around the garden and that serves as a justification for the price tag. It's the wrong way of doing things because business. It's exactly the same evil principle as the one which is at work when the sugar or the tobacco industry do their slightly questionable stuff.
You're not wrong, but perhaps that's an indication that software companies should use language & environments which enable them to have fewer developers, and enable those developers to keep track of things like resource usage?
Whereas traditionally you would have an engineer responsible for part of the application as time goes by, making sure that it works better while maintaining quality.
Want inline pictures? Well, Textual has had that for a long time, irccloud's webUI too.
The amounts of memory that users are reporting for Slack are all several times higher than the entire RAM of the first computer I started using my MSNP client on.
I had to walk 10 miles to school in the snow! Barefoot! Uphill! Both ways!
or
GET OFF MY LAWN!
Spritesheets can be disabled under Advanced.
Maybe it helps, sorry I have no before/after but my Slack is sitting at 300MB right now and I deal with an high number of very active channels.
You must be overlooking all the helper processes.
I've switched over to using mattermost, it can be (and is) self hosted so I'm not as worried about slack getting hacked (again) and leaking our info/taking control of our systems with chatops.
The downside is; mattermost is not a strong replacement. I wrote a bot to basically do a large part of my job for me, and coding against mattermosts websocket protocol and dealing with authentication has been messy to say the least.
Slack is a joy to code against and use from a UI perspective when compared. (sadly, as I don't like it for ideological reasons)
Here's a fun one: say I use the MIT binaries, then debug a problem by reading the AGPL source code. What legal position am I in? (If you have an answer for that rhetorical question, by the way, you haven't thought of the problem long enough.)
https://github.com/mattermost/mattermost-server/blob/master/...
They launched exclusively AGPL and then made MIT as a concession after discovering that a number of companies outright ban AGPL and won't pay for it unlike MongoDB, but licensing binaries differently than source code is not something you come across often.
On a side note, Last Chance to See is a great book (Douglas Adams) and show (Stephen Fry), highly recommend both of them.
And it's completely absurd that mine is currently using 1514MB of memory.
If I weren't required to use Slack on a day-to-day basis, I absolutely wouldn't solely on principle.