Live data from Hacker News

Incident at Slack

status.slack.com

91–96 of 96 posts

Re: Incident at Slack

#91
post #49

Earlier quoted context omitted.

No, not really. If your calls time out, ping the status server. Done. It sounds more like laziness than complication to me. But that typifies Slack dev culture—“just use duct tape”

And that's exactly how you DDOS your status server.

Put a CDN in front of the status server. If that overwhelms your CDN then add some exponential back off to the mix.

Re: Incident at Slack

#92

Earlier quoted context omitted.

I can't work out why you wouldn't develop a native app anyway - all this scaffolding in a Web UI to imitate native controls (like menus) seems completely backwards to me. Seems just lazy, but in an odd way because writing native apps isn't rocket science or difficult. It's not like they're implementing thousands of native controls or user interface components - a listview with an edit box at the bottom...

> It's not like they're implementing thousands of native controls or user interface components This is not true in any way. Slack also have workspaces, channels, notifications, video calls, file sharing, admin tools and probably even more features. It's not just IRC. Maybe writing a web-based app is lazy... except when you have to write native apps for macOS, Windows, Linux, Android, and iOS, and some people still ne…

This is a bad argument that is factually incorrect in some ways.

Slack already has three different clients - a web one (which includes the Electron desktop wrappers), one for Android, and one for iOS.

They've already demonstrated that they have the engineering resources and coordination to develop and maintain three completely separate clients (albeit poorly) - so adding a fourth one (native C++ codebase using Qt that would work well on Windows, Mac, and Linux) would not be the Herculean engineering effort required to go from one to five, and your implicit assertions that (1) they currently only have a single client and (2) that a different client would be required for each of Windows, macOS, and Linux are simply false.

> But a webview wrapped in i.e. Electron handles most of it for you! Why would you do it any other way except to appease people who complain about bloat?

Because (1) performance (2) accessibility and (3) stability - the things that users actually need. Slack's performance is extremely bad and you get people constantly complaining about it; their accessibility is janky and suboptimal because they're reinventing desktop UI controls on the web; and their applications have repeatedly broken (such as the disastrous input box rewrite[1]) because they're trying to do things with the web platform that it wasn't meant to do. (in case you're wondering how using a desktop client would help - you expose a "lite" version of your functionality in the web application and put the full functionality in the desktop tool)

You're using "appease" as marketing-speak for "fix the very real problems with their web application that people constantly complain about". Slack should fix their application because it isn't serving the users well. Performance problems are functionality problems.

As it stands, Slack is showing us that they aren't even pretending to care about their users - they're just trying to make a buck selling to large organizations.

[1] https://news.ycombinator.com/item?id=21589647

Re: Incident at Slack

#93

I find slack so bloated and slow it would probably take me about 15 minutes to realise it was actually down.

Slack should develop native apps now as they are no longer a lean startup and can afford to build native apps.

It’s also important to remember that writing native apps doesn’t inherently inherently give you a big performance boost. With the type of app Slack has, I would expect the default implementation in a native app to be pretty slow as well. You’d have to do a significant amount of further optimization to make it competitive, imo. And to be honest, I imagine if someone applied that same amount of optimization and effort to the electron app, they could make the performance much better there as well.

Re: Incident at Slack

#94

I find slack so bloated and slow it would probably take me about 15 minutes to realise it was actually down.

Slack: the best tool for the job! (when the job is firing off gifs and rocket ship emojis to your coworkers instead of whatever it is that keeps the lights on at your company).

Re: Incident at Slack

#95
post #67

Earlier quoted context omitted.

I can't work out why you wouldn't develop a native app anyway - all this scaffolding in a Web UI to imitate native controls (like menus) seems completely backwards to me. Seems just lazy, but in an odd way because writing native apps isn't rocket science or difficult. It's not like they're implementing thousands of native controls or user interface components - a listview with an edit box at the bottom...

> I can't work out why you wouldn't develop a native app anyway Really? One code base, one language, write features once. I think it's more about eng resourcing (headcount, onboarding, roadmap parity / feature drift, etc) than whether making a native app is hard. Anecdotal, but I feel like the React Natives and Electrons have made it so you see less "Sorry we're only on Mac", and "We're only on Android, iOS coming so…

> so you see less "Sorry we're only on Mac"

There's the problem, nobody's sorry for offering only these static 100MB chat clients taking 2GB+ of RAM once launched. These apps are technically ridiculous, especially since all they do is embed a website. I mean, if all your company's willing to deliver is website, why even bother with the apps... But that's all fine right? We'll just upgrade to 64GB and 128GB machines soon!

Re: Incident at Slack

#96

I find slack so bloated and slow it would probably take me about 15 minutes to realise it was actually down.

Slack: the best tool for the job! (when the job is firing off gifs and rocket ship emojis to your coworkers instead of whatever it is that keeps the lights on at your company).

It's fun sometimes, but other times it really takes away from the conversation.
Post reply on HN