In my experience custom emojis is the most important driver of Slack use ;).
Maybe it was the ui, or some particular features, but they did resonate with the users. And now they are the benchmark that all the others will compare to.
A chat client should not be taking over 1GB of RAM
Literally no one knows! It's layers upon layers of code. Most of the layers can't even be understood by a single person, let alone the whole program.
You meant 1MB, right? ;-)
* I recognize your sarcasm, but figured I'd reply anyway since the internet is a weird place and lots of people might not catch the joke.
[1] https://medium.com/@matt.at.ably/wheres-all-my-cpu-and-memor...
I also use Discord which uses Electron and with it, I'm on 8 separate active servers with anywhere from 10-30 channels. This sits at 115mb without an issue.
Can you tell me where these electron metrics come from where people have slack take up 1gb or even 2gb of memory?
That's still a lot of RAM for a chat with giant emojis.
You have to consider that people reporting these issues with memory consumption are running the app in different operating system than yours. Maybe your system is optimized. I just checked my co-workers computer and his main Slack process is at +97MB but there are 3 instances of "Slack Helper" at +433MB, +297MB and +255MB respectively. That's over 1GB in total. So either you are just looking at the main Slack process (which at +340MB makes sense) or your Slack is leaking memory somewhere that your RAM monitor is not able to map.
Why do you care so much about RAM usage? All this concern over RAM is completely missing the picture here.
Every conversation about slack or electron people complain about RAM usage. The market could not give two shits about RAM usage so why does everyone on HN complain about it?
That's fucking bonkers. Objectively and scientifically fucking bonkers.
(Great tool, much better than the awful official client, but 20MB is actually a lot of RAM.)
But I think it's more useful to think about the percentage use of RAM for a given application. If you're running on a machine with 32 MB of RAM, then using 20 MB for a single application is obscene. But if you're running 32 GB, it's insignificant.
Even so, a single application shouldn't be using a significant percentage of system RAM on an average consumer grade laptop/desktop (4 to 16 GB of RAM).
I'm currently on a 16GB machine, where I only have a terminal, a text editor and a browser with few (<10) mild (wikipedia, hn, ...) tabs open. That gives 351 processes using a total of 8.7GB memory (2.11GB of which is unswappable, and about 1 gig of already compressed memory). My 3GB of disk caches go on top of that, and 0.5GB has already been swapped out.
I sure have room for a 20MB binary right now. However, on an 8GB system, I'd be in the red. I would already be swapping several GB, and any allocation would either evict (useful!) caches or swap out the memory of another process.
Any memory allocated in that state reduces the performance of some other component of the system.
Of course, 20MB is much better than the status-quo of casually burning a few hundred MB (or even a few GB) for simple tasks, and the situation of being out of memory with a whopping 8GB is caused primarily by the other "bad citizens", but the point here is that 20MB is indeed a quite big chunk of memory in real-world use-cases.
Especially for this application, which presents a UI from 1990, and the functionality of an IRC client.
https://get.slack.help/hc/en-us/articles/201727913-Connect-t...
Maybe one day!
It couldn't be that rough, could it? I've done little interacting with the API's outside of simple bot integrations for a little fun.
I presume most of the non-commercial projects posted on HN are started to scratch an itch of the autor, which might as well be that they're stuck with a closed system that sucks. Trying to improve that situation somewhat seems sensible to me.
I don't understand this world any more
I have been lurking on a few IRC channels due to my work on http://www.oilshell.org/ .
Problems I noticed:
- The lack of conversations/threading is really annoying. Most worthwhile IRC channels have more than one conversation going on at once. Not only do you have to untangle who's talking to who, there's no way to know where the beginning of a conversation is. I have to read messages backward to find the beginning .
- By default there seems to be a lot of leave/join spam. I used IRC for a year before turning this off and it vastly improved my experience.
- I think most clients don't save anything by default. When I reboot my computer and don't log in again, I miss messages.
- Having to use pastebins for code is annoying.
I'm sure that someone will respond with how you can solve all these problems with a certain IRC client. But I don't want to do that. I'm not technically unsophisticated -- I write software in 5+ languages and I know all about Unix and networking. I just don't want to spend my mental energy on my chat client -- I have tons of other projects to spend it on.
So I only use IRC when necessary; I use e-mail otherwise (through GMail.)
Of course, I also don't use Slack. But from what I hear it solves some of these problems.
An open protocol, free choice of clients, and decentralised infrastructure is a baseline. A change is not an improvement if it removes those. (You could argue you have valid reasons to remove any of them and you'd be wrong.)
I don't see why it would be much more exhausting to use a hosted IRC service like IRCCloud to solve your problems than pick a specific alternative protocol entirely.
Clicking through to oilshell - I wanted to know what is different and exciting about it, but all I found was text saying it's "new". Making the value proposition clearer would go a long way and be a big help to people who are curious and geniunely want to understand what's amazing about your creation.. !
I find it interesting that people want to have threaded conversations in what is essentially a synchronous chat, but they prefer to have a degraded threading experience in their email client by using conversation view rather than traditional email threading using the Reply-To and/or References headers.
> The lack of conversations/threading is really annoying.
Slack is arguably worse - they recently added threading (really comments that can go on a post - there is no nesting), but this has made me much more likely to miss any follow-up because messages are less visible than otherwise.
> By default there seems to be a lot of leave/join spam. I used IRC for a year before turning this off and it vastly improved my experience.
This is entirely client dependent, so not really a fault of IRC. Slack has the same option, it just defaults to not displaying it like clients as opposed to whatever IRC client you used.
> I think most clients don't save anything by default. When I reboot my computer and don't log in again, I miss messages.
Yes. I don't know the inner workings, but generally if you're offline on IRC you will miss anything directed at you. Slack definitely addresses this, and it is my favorite "feature" - it means that Slack is not good for only casual discussions. (Slack's search is my second fav, and there's nothing special about that, it just works well enough that I can usually find that comment I vaguely recall someone making within the last 6 months on one of the many channels I'm on).
I expect this is largely a client issue, though I also imagine that most IRC servers have a very limited amount of immediately available conversation. Remembering that you have direct messages waiting for you would require servers that reserve nicks. That's all guessing though.
- Having to use pastebins for code is annoying.
Slack allows for posting code in text, posting text "snippets" that can include code, and posting files that can be downloaded.
Overall your frustrations seem very reasonable, but from the sound of it you're "hanging out" on IRC channels that are being friendly for outside users to drop in and out, and for devs to have conversations that are considered temporary. Plus not having users post goatse pics or worse. Which means they aren't even TRYING to accomplish what you want. Hard to blame IRC in that case - those features aren't used even when available.
I'm not exactly saying "You just need to use IRC client X" as you predicted, but more "you probably just need to change a config and connect to IRC servers that are INTENDED to do what you want". Not wanting to go through that effort is fine, and I'm not saying Slack and other alternatives are worse or even equal for those tasks, but don't blame the plane for not flying when the pilot is making donuts on the runway.
Why do I have to sign up for different Slack organizations and have a different password for each one?
Why can't I private message someone on Slack with just a username?
I think Discord does this much better.
About the only thing IRC has going for it is decentralization, and that's not very valuable in the market it seems.
Seriously. IRC has had 30 years to get with the times. It's stagnated and been lapped by its competitors, and the efforts to improve it didn't properly start until Slack and friends simultaneously re-cooked and ate everyone's lunch and dinner.
I did it because I like IRC, but my employer (and many of my co-workers) love Slack.
I dislike Slack, having the option to connect to an IRC gateway (unless your employer disabled this option) or to communicate with their API service with a program like this one (linked above) or mine (linked below) is good for people who still need to communicate with their peers but want to do so through the program that they are more comfortable with, in this case, the Terminal.
- Huge, rigid, unskinnable UI. - Difficult, multi-step access to configurations and settings. - No OS integration therefore no desktop automation.
I probably should have stuck with Hipchat, but I jumped on the Slack bandwagon along with everyone else.
And slack is complete garbage that is pushed and we as employees most of the time have no other options.
Besides the whole problems mostly talked about related to memory and cpu usage, the one nobody seems to check or understand is that it is completely frustrating and unusable from accessibility point of view. I've seen this first hand as that person above is blind and the slack application is of one the worst offenders there is regarding this point. I've seen and felt his frustration and how slack team manages to avoid his point all the time.
So I hope it dies out eventually :D
Different people, different needs, different drivers. Just don't expect the actions and motivations of different groups of people to align with each other. Sure as a while it doesn't seem to make sense but each individual part is reasonable on it's own. There must be a powerful German word for things systems that look crazy at the macro level but are reasonable at the micro level.
This terminal client seems to be using Slack's public web API.
https://github.com/bkanber/Slackadaisical
Been using it, works fine as well. Good job OP though, diversity of offering is always good!
Haven't tried this plugin myself though.
I actually do use this, but it is missing a lot of useful features, some of which seem unimplementable in IRC
One example: the mattermost clients won't register a message as "read" until you switch to that view, so if e.g. I check messages on my phone, I will see unread messages, but IRC doesn't have a way of communicating this between client and server so matterircd seems to mark all messages as "read" with mattermost)
Yes I know about irssi and friends, but they're not really having an UI, many things are commands or config based, but centericq was.
(not to imply that the electron app isn't nicer to some people)
Is that how much memory this requires to run?