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.

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.