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

Tell HN: Slack decides to close down IRC and XMPP gateways

news.ycombinator.com

Post reply on HN
Print view View original

281–290 of 624 posts

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#281

Post by bananaboy »

s73v3r_ wrote: post #226
panopticon wrote: post #175

Earlier quoted context omitted.

The web-based implementation means you only have one codebase for both Slack in the browser and Slack in Electron. So adding Qt in addition to their browser client means they have two disparate clients instead of one client (plus Electron glue code).

So what? You're saying that like it's this terrible thing. It's not. Especially because, as has been shown, Electron apps are extremely sorely lacking in things like accessibility.

Yeah, but unfortunately businesses prefer to sacrifice user experience for developer convenience and expediency. I wish it weren't true.

There are a couple of cases where you can avoid that in the text editor and source control space: Sublime Text is cross-platform and native, and so is SourceTree (although it's become quite buggy). So just avoid GitKraken, GitHub Desktop, VS Code, Atom.

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#282

Post by progval »

> After years of evolving, Slack is at the point where the gateways can no longer handle all of our features or security needs.

I don't think Slack ever cared much about the gateways. I have used the IRC gateway for years, and it was never compliant with IRC protocols. I even had to patch my IRC client to work with Slack.

IRC is also being extended with new features [1], some of which are designed specifically for gateways to services like Slack. But Slack never used these. It does not even use features that are supported by all IRC clients literally for decades (eg. AWAY)

[1]: https://ircv3.net/

Could you be more specific about what features IRC/IRCv3 lacks?

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#283

Post by jsmthrowaway »

bartread wrote: post #242
jsmthrowaway wrote: post #34

Earlier quoted context omitted.

I remember when Slack in a Chrome tab committed 3-4 GB. Sounds like they've made improvements. Standalone client and its helpers are sitting on ~800MB committed on my install of High Sierra. Might be worth a shot.

For the love of Pete! It's a frigging IM client: 800MB is absolutely not a reasonable amount of memory for it to be consuming, and I don't care how long your message history is. 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).…

Preaching to the choir, man. I was just saying the Slack bleeding could potentially be lessened by wielding a slightly different model of chainsaw. I certainly want my gig back.

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#285

Post by gruez »

dman wrote: post #274
arvinsim wrote: post #255

Earlier quoted context omitted.

If doesn't affect their bottomline, then why will they bother?

Customers are fickle beasts, they mutter and keep on using a product until they dont.

yet there's no slack competitor that has "better battery life" or "native apps" as one of its selling points.

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#286

Post by jest3r1 »

saltcured wrote: post #15

This change, if it goes through, means I will disengage from Slack other than passive browsing from their Android app. My teammates will have to remember how to read email if they want non-trivial input. It feels like a mixed blessing though, as it is a nice excuse to detox from this mess.

Well email is due for a comeback.

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#287

Post by jest3r1 »

nopacience wrote: post #32

Slack was fine, now it is time to move back to IRC. Some people like slack or telegram because they provide an API for BOTs. Something IRC has been open to since the begining. Non power users might have trouble using IRC with the usual clients (mIRC/irssi/bitchx). Today a family member, not technical and 60+yrs asked about "that tool" that is like whatsapp however it allows users that just joined a group to read old…

Non power users might have trouble using IRC with the usual clients (mIRC/irssi/bitchx).

I've never used Slack but these name drops are all familiar.

Back in the good 'oldays of Eggdrop? It's amazing that Slack was "backwards" compatible with IRC for so long.

But honestly, their API is mature. No need to be backwards compatible. Easier to sell when you are in control of access and client.

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#288

Post by bananaboy »

Dunedan wrote: post #41

Well, another day of being disappointed by Slack. Aside from missing native clients mentioned in other comments my biggest pain point is their awful implementation of threads. Every time I think: They must be kidding, they can't be serious, that's just a bad dream. A few examples: - The only place where you get noticed about responses to threads is the "New Threads" view, which makes it easy to miss responses, when y…

Oh wow I'm glad I'm not the only one who hates the threads implementation. It's an awful user experience!

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#289

Post by [deleted] »

saagarjha wrote: post #120
bramd wrote: post #92

Earlier quoted context omitted.

Well, in this case I was quite glad that they have targeted the web platform. At least that allows me to code my own stopgap solution using userscripts and stuff. That's harder for native.

With native apps, you don't need to . Good accessibility solutions are the default.

[deleted]

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#290

Post by abugher »

welder wrote: post #267
blindgeek wrote: post #229

Earlier quoted context omitted.

So much this! I happen to be a blind software developer who has had just this sort of experience in years gone by. Web apps mean that you are at the mercy of the developers. Something can work one day and break the next. This is even more true for blind people than it is for the general public. Even if there is accessibility testing, I doubt that it covers my particular toolstack. I'm on Linux. So I'm doubly a niche…

Besides building accessibility into frontend/React component toolkits, how do we automate testing for accessibility? I've turned on text dictation and tested apps with a blindfold, but that doesn't scale and I'm not even sure if it's how people really use an app without sight.

Tangent:

I think you should really have someone who hasn't seen the app test with the blindfold.

Is that double blind, or just single blind plus literally blind?

Post reply on HN