Live data from Hacker News

When a rewrite isn’t: rebuilding Slack on the desktop

medium.com

51–60 of 408 posts

Re: When a rewrite isn’t: rebuilding Slack on the desktop

#51

How about a native client? I think it's safe to assume that Slack has the resources for this.

No company has infinite resources. Maintaining native mac and windows apps to appease the few people who have an irrational hatred of electron doesn't make good business sense when those resources could be going work that actually improves their product in a meaningful way.

They are already maintaining apps for each platform.

The question is whether the shared part is written in C++ vs. JavaScript.

Re: When a rewrite isn’t: rebuilding Slack on the desktop

#52

Good news for the Slack team, as this means they'll no longer be the poster child for "look how bloated Electron apps are! Slack takes up x gigabytes of RAM!" Great work, Slack team.

I can still say "Look how bloated Electron apps are! Slack takes up half a gig of RAM!".

Re: When a rewrite isn’t: rebuilding Slack on the desktop

#54
post #44

Earlier quoted context omitted.

Past a certain point, the downsides of Electron outweigh the downsides of native apps. We've crossed that Rubicon years ago.

If this was the case we wouldn't see so many Electron apps. You just don't perceive enough of the upsides to see why the decisions are being made.

The upsides are for the companies shipping it, the downsides are for the users. So it's not a surprising outcome.

Re: When a rewrite isn’t: rebuilding Slack on the desktop

#55

How about a native client? I think it's safe to assume that Slack has the resources for this.

Nobody has the resources for that. Some companies make OSes, and some companies send rockets to space. Those feats are also powered by thin wrappers over electron. /s People seem to forget that C++ and opengl is cross-platform. And there are projects far bigger than slack, like ffmpeg and OpenCV that have existed for decades, always had very fast development cycles, with only a subset of the funding and money that Sl…

It is telling that the person arguing in favor of native C/C++ has to use a throwaway account for fear of going against the dominant force of opinion in our industry. We should be able to have these conversations openly without wondering if it makes us less employable.

Re: When a rewrite isn’t: rebuilding Slack on the desktop

#56
post #7
post #5

I was so happy they had finally gone native. The disappointment is strong. On a side note, SBlack, a lightweight slack client is very impressive on memory usage [1]. 1. https://www.sblack.online/

How does this work? I thought Slack deprecated their IRC gateway; is this all API-based then?

They advertise 20 MB instead of 180 MB and not being Electron, so I would bet it's Slack's web client wrapped in macOS's built-in WKWebView, plus some custom CSS to support dark mode.

>Sblack works exactly like a browser with small tweaks. We inject the dark mode style at the end of the Slack’s html, and that’s it.

Another benefit of this is that Safari/WebKit does better with battery life than Chrome. I'll have to give this client a look.

Re: When a rewrite isn’t: rebuilding Slack on the desktop

#57

Earlier quoted context omitted.

Nobody has the resources for that. Some companies make OSes, and some companies send rockets to space. Those feats are also powered by thin wrappers over electron. /s People seem to forget that C++ and opengl is cross-platform. And there are projects far bigger than slack, like ffmpeg and OpenCV that have existed for decades, always had very fast development cycles, with only a subset of the funding and money that Sl…

It is telling that the person arguing in favor of native C/C++ has to use a throwaway account for fear of going against the dominant force of opinion in our industry. We should be able to have these conversations openly without wondering if it makes us less employable.

You shouldn't make assumptions about why someone's account is named throwaway.

Re: When a rewrite isn’t: rebuilding Slack on the desktop

#58

How about a native client? I think it's safe to assume that Slack has the resources for this.

The fact that nobody's gone out on their own and built a native client means at least one of four things is true:

1. Slack is too restrictive, and its API is too poorly supported for anyone to create a port. I find this unlikely, given that the API is extensively documented and that an Emacs port already exists, but maybe there are problems I'm not aware of.

2. Good native ports are actually a lot harder to build and maintain than typical HN posters claim.

3. For all everyone complains about Electron, maybe the current app is good enough for pretty much everyone, including the complainers, and those complaints are largely just hot air.

or 4. A few good, Open Source native ports already exist, and people are just unaware of them.

Regardless, the HN crowd is made up of developers who know how to develop things and use experimental software -- most people on here know how to extract a login tokin, and a lot of people on here are willing to put in a lot of effort to solve problems. If there isn't a native port already, there's very likely a good reason for that.

If there isn't a good reason for it, and it's just that somehow nobody on HN has thought to sit down and build a native app yet, then I'd welcome one, I suppose. But obviously I'm not annoyed enough by Slack to do it myself, and I suspect that most other people posting here fall into that category as well.

Re: When a rewrite isn’t: rebuilding Slack on the desktop

#59
post #44

Earlier quoted context omitted.

If this was the case we wouldn't see so many Electron apps. You just don't perceive enough of the upsides to see why the decisions are being made.

The upsides are for the companies shipping it, the downsides are for the users. So it's not a surprising outcome.

Tell that to people who want to use modern services on a Linux workstation
Post reply on HN