Hacker News new | past | comments | ask | show | jobs | submit login

Yes, by innovating and giving people the user experiences they want.

IRC is a joke once you’re used to Slack, especially in an organization that uses it well.




I appreciate having a streamlined chat application, but understand that others feel differently. IRC applications are much better on resource consumption and snappier in my experience, but aren't all that practical on a mobile device.

Naturally, how each of us feels about that experience is subjective. So setting that aside, the part about IRC that I haven't seen handled with Slack is being a one-stop shop. With IRC, I can discover and access multiple communities within a single server at once. The most popular servers can be connected to and browsed with a click in most IRC applications. With Slack, I need to find a project's Slack workspace, request an invitation, then go through the process of adding it to each of my clients. I'd love to see the equivalent of a FreeNode workspace where I can join an OCaml channel and a Ruby channel without going through all of the above and dealing with walled-off communities.

Revisiting resource consumption, I've opted out of communities that moved to Slack because once I hit around 10 workspaces, the Slack app slowed to a crawl and guzzled RAM. To be fair, that's gotten a lot better in recent years, but I still find managing several workspaces to just be too much cognitive overhead. I may only be in one channel on each workspace, but I can't easily switch between them. With IRC, doing a "/join ##ocaml" is super fast, barely consumes additional resources, and adds a new tab to my main interface for fast switching between channels.


The big thing I miss in IRC is that I can't just open my IRC client, connect to a channel, type a few messages, close the client again, do other stuff, come back a few hours (or even days) later, and see if there are any replies to it.

I know about IRC bouncers and all that, but I don't want to set up a server just for that, and managing them is a pain as well. I know about IRCCloud too, but I don't use chat often enough to justify $5/month (I'm poor, and I just want to chat occasionally).

I don't care much for Slack for many reasons, but at least I can actually use it. I find IRC to be functionally unusable because of this.

From a quick glance, it looks IRCv3 solves this with the chathistory extension/specification.[1] But AFAIK most (no?) servers implement this (yet) and the specification isn't finished either.

https://ircv3.net/specs/extensions/chathistory


That's fair. Async communication is not its forte. There are definitely times I wish I could communicate with someone that way. Some channels have a logger and that can be helpful. For the most part, I like the "inbox zero" approach. I can hop on and just start chatting and there's no cultural expectation that I've gone through pages of chat logs from the last time I left.


> I know about IRCCloud too, but I don't use chat often enough to justify $5/month (I'm poor, and I just want to chat occasionally).

I'd also add that I've often seen IRCCloud banned from many channels due to extreme amount of spam from their users.


I also abandoned Slack completely due to its horrendous performance and UX. I find comments like the parent above you utterly perplexing.

There are Slack gateways that exist for native applications. I currently use a Slack libpurple plugin with Pidgin, and although threading is slightly cumbersome, eliminating Electron and/or a browser has greatly improved my experience overall.


I didn't mind using slack when they had an IRC gateway.


IRC is a protocol

Slack is a product

There is a really big difference


The thing is, I don't want these experiences. Am I allowed to stop having them now? Turns out: Not if I want to keep doing my job.

Burn Slack to the ground is my considered stance at this point.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: