Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slack client for the terminal

github.com

Post reply on HN
Print view View original

161–170 of 184 posts

Re: Slack client for the terminal

#161

Post by flamtap »

dawnerd wrote: post #119
rockostrich wrote: post #89

Earlier quoted context omitted.

It's based on Electron[1] which has a reputation for being a bit of a resource hog. The upside is that it makes it really easy to create a cross-platform app. [1] https://electronjs.org/

I use quite a few electron apps and none of them seem to get that bad except maybe atom but I have a TON of open windows.

Slack gets pretty resource-intensive when the user is part of multiple workspaces. I know one of my co-workers is part of three or four, whereas I'm only part of the main company workspace. Co-worker's Slack memory usage is around triple that of my own.

Re: Slack client for the terminal

#163

Post by ptman »

I would hope that people would spend their effort improving open systems instead of closed ones. The same effort could be spent improving matrix (via a terminal client if one of the existing ones don't suit or improving the slack bridge or implementing features slack has and matrix is missing)

Re: Slack client for the terminal

#164

Post by ptman »

kqr wrote: post #68
chubot wrote: post #50

Earlier quoted context omitted.

I love using Unix and the terminal, but I hate using IRC. I don't think it works "perfectly fine". 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…

I think you are focusing on the wrong thing by spending several paragraphs on the problems with the out-of-the-box experience and only one on the fact that it is an open protocol so a sufficiently technical user can fix it . 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…

btw, you can also use matrix.org and their irc bridges to various irc networks in place of irccloud

Re: Slack client for the terminal

#165

Post by btschaegg »

ptman wrote: post #163

I would hope that people would spend their effort improving open systems instead of closed ones. The same effort could be spent improving matrix (via a terminal client if one of the existing ones don't suit or improving the slack bridge or implementing features slack has and matrix is missing)

While I would generally agree with the idea, I think it's also important to see that people aren't always in the position to choose said open systems.

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.

Re: Slack client for the terminal

#166

Post by lewisinc »

qudat wrote: post #148
NikolaeVarius wrote: post #9

I use this personally. Its great. Hides all the cruft that people post in slack as text. I've been working on trying to extend it on the side. A chat client should not be taking over 1GB of RAM

> A chat client should not be taking over 1GB of RAM 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?

My computer is like a garden - treat it with respect or we can’t be friends.

Re: Slack client for the terminal

#167

Post by arghwhat »

mikewhy wrote: post #142
arghwhat wrote: post #130

Earlier quoted context omitted.

The price of RAM is not a relevant parameter. Why should 20MB hold less information today than it did in 1990? Especially for this application, which presents a UI from 1990, and the functionality of an IRC client.

> Why should 20MB hold less information today than it did in 1990? 64-bit, for one.

Yes, that gives a slight increase in memory consumption. We can go overboard and allow a doubled memory consumption then.

Re: Slack client for the terminal

#168

Post by arghwhat »

aidenn0 wrote: post #139
arghwhat wrote: post #130

Earlier quoted context omitted.

The price of RAM is not a relevant parameter. Why should 20MB hold less information today than it did in 1990? Especially for this application, which presents a UI from 1990, and the functionality of an IRC client.

Because the engineering costs have not gone down so it may not make sense to spend the effort to reduce memory usage.

I suspect you might think I demand that every byte is used absolutely optimally.

I'm sure some crazy chap out there could write this application with only a few hundred bytes of memory, but that's beside the point.

Re: Slack client for the terminal

#169

Post by arghwhat »

qudat wrote: post #149
arghwhat wrote: post #130

Earlier quoted context omitted.

The price of RAM is not a relevant parameter. Why should 20MB hold less information today than it did in 1990? Especially for this application, which presents a UI from 1990, and the functionality of an IRC client.

> which presents a UI from 1990 Disagree, the reason why it is so popular is because of its slick UI. > and the functionality of an IRC client. Disagree. Did you read the other comments? An IRC client is not the same as a SaaS chat service that keeps history, video chat, infinite scroll, allows communication to happen even if a user is not online, etc. Sorry to sound so harsh but saying that slack is just an IRC clie…

> Disagree, the reason why it is so popular is because of its slick UI.

I think you misunderstood my comment as being negative. I like TUI's, but it's a UI from 1990's, and the resource requirements for rendering such a UI has not increased since the 90's.

> Disagree. Did you read the other comments? An IRC client is not the same as a SaaS chat service that keeps history, video chat, infinite scroll, allows communication to happen even if a user is not online, etc.

You are missing the point entirely here. First of all, I am not saying that Slack should go away because it doesn't do more than IRC. I am, however, saying that I expect similar resource consumption.

But to tear the idea of there being a difference apart:

"SaaS" is irrelevant. It does not affect features, and Slack is just as much a service as freenode is. No difference there.

This client does not provide video chat, so that's irrelevant.

This leaves us with "history" ("infinite scroll" is just a UX decision) and "allow communication to happen even if the user is not online".

Communication to happen while the user is online is handled in IRC through an IRC bouncer. So, what you're saying is just that the Slack server has a built in bouncer. Not something that takes client resources, or differentiate it from IRC.

So in reality, the only fancy feature Slack has is synchronized history. This is a nice feature that IRC doesn't have, but it takes 0 client resources to implement. It just requires some storage on the server and a synchronization protocol, which could be as simple as "dump the history when the client connects".

> Sorry to sound so harsh but saying that slack is just an IRC client with a 1990s UI shows a complete lack of understanding for why it has dominated the market for business chat.

Sorry to sound harsh, but Slack does not differentiate itself through features. Just like Atlassian HipChat, it doesn't do more than IRC + 1 or two simple features (which in no way complicates the platform or increase resource consumption).

What it does is to wrap an entirely standard feature set in a package more easily consumed by the users in this day and age, that might be turned off by things like IRC. That in itself is an entirely fine proposition, and one which have had success. However, the features are indeed those of an IRC client, and the resource consumption should be thereafter, especially when you go full circle back to having a good old TUI.

Re: Slack client for the terminal

#170

Post by zimpenfish »

LocutusOfBorges wrote: post #10
kylehotchkiss wrote: post #3

I just want something between this and Slack's mac app, which sometimes doesn't want to load on even Starbucks wifi. Ideally a GUI app that can load messages on airplane wifi would be amazing. Every time I try to open slack on an airplane it just sits there loading and loading and loading. Maybe one day!

Eul seems like it might fit that requirement: https://eul.im/

I tried the latest Mac version. Crashed instantly I tried to log into Slack. Maybe in a few revisions it'll work but for now, it doesn't seem to.
Post reply on HN