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

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

medium.com

Post reply on HN
Print view View original

121–130 of 408 posts

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

#121

Post by stephenr »

notatoad wrote: post #93
stephenr wrote: post #77

Earlier quoted context omitted.

Slack is the only web-app I’ve seen that routinely triggers the safari warning about its resource usage/affect on performance. For years slack has been a resource pig on desktop and on the web. So what improvements are you imagining they’ve been working on? Chatting on the internet is hardly such a groundbreaking subject that it can’t be done efficiently.

>So what improvements are you imagining they’ve been working on? the ones that are described in the blog post that you're currently commenting on

The very problems that were caused by not having native apps.

Thank you for making my point for me.

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

#122

Post by stephenr »

notatoad wrote: post #85
ch_sm wrote: post #29

Earlier quoted context omitted.

not irrational. the performance problems can be measured and are noticeable in everyday use.

how can you measure the performance difference between an app that exists and one that doesn't?

Chat apps have been around for literally decades. There’s plenty of prior and current competing apps that do essentially the same thing and use a fraction of the resources.

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

#123

Post by danShumway »

dmitrygr wrote: post #84
danShumway wrote: post #58

Earlier quoted context omitted.

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…

5. how can I make $$$ from spending a few months writing a native client? Slack can cut me off anytime they get annoyed with me. So even if my client is better, they can decide i am a threat and cut me off. Never build your future on someone else's platform.

I completely agree, but this would fall under point 1 for me.

See Twitter for a good example of where business interests and API stability intersect in negative ways. I would make the point that if you don't trust a business to keep their official API stable, you probably shouldn't be building a community around their tools in the first place, regardless of whether or not they have a native app.

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

#124

Post by chinhodado »

mcguire wrote: post #103

" Conventional wisdom holds that you should never rewrite your code from scratch, and that’s good advice. " Speaking as someone who has done a fair number of rewrites as well as watching rewrites fail, conventional wisdom is somewhat wrong. 1. Do a rewrite. Don't try to add features, just replace the existing functionality. Avoid a moving target. 2. Rewrite the same project. Don't redesign the database schema at the…

There's this classic article on the topic: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

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

#125

Post by jumbopapa »

phlyingpenguin wrote: post #120
nik736 wrote: post #98

So for people who only use one team nothing has changed?

The hack I used to use to inject CSS into the app for a dark theme is no longer viable. So that changed.

I got the dark theme to work. Would you be interested in a write up?

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

#126

Post by ausjke »

ausjke wrote: post #41
me551ah wrote: post #20

For me the gold standard of Chat applications is always going to be mIRC. It supports a ton of plugins, consumes 10-50mb of memory and little to no CPU. You could be connected to multiple servers and channels with DCC scripts running and you still wouldn't notice that it's even running. Even though Slack is using react now, they are still using electron under the hood. Which means it can never match the snappiness of…

mirc is windows only? there are many web-based irc these days and they worked well

interesting, so I checked out mirc and reported it's windows-only(hope to save someone sometime), and since I used irc over browser so I added some info for that. Still, obviously someone disliked this sort of comments and downvoted, I'm always surprised by downvotes like this sort, any bystander can shed some lights? Am I supposed to always write a cheerful comment for basic neutral truths?

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

#127

Post by doc_gunthrop »

zeusly wrote: post #8

I wonder if they increased their efforts after seeing VS Code (also a complex Electron app) run fast and memory-efficient. Before VS Code everyone just accepted Electron's memory bloat, maybe slack even had plans to go fully native b/c no one thought it could be done properly.

> memory-efficient.

Not how I'd describe a text editor that consumes 700MB+ of RAM at any given time.

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

#128

Post by msbarnett »

somethingnot wrote: post #111
msbarnett wrote: post #78

Earlier quoted context omitted.

It’s little more than a simple IRC client that consumes 250-500 megs of RAM. I wouldn’t take any victory laps over the supposed “efficiency” of Electron here.

Yeah, and a Rolls Royce is little more than a Honda with worse miles per gallon.

Except in this metaphor, in terms of features, performance, and sheer quality of experience, a Rolls Royce would be something like LimeChat, and Slack is a Ford Pinto

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

#129

Post by _verandaguy »

matchbok wrote: post #48
Klonoar wrote: post #32

I will consider this benchmark vindication both for myself and the times I've had to argue as to why Electron isn't the issue, as well as the commentator from many moons ago who worked at Slack, dropped in here and explained why Electron wasn't the problem (rather, poor engineering on Slack's part was), and then was ripped to shreds over it. In fact I'm sure this comment will bring out native fanatics in force. At an…

And yet, the performance is still bad. And that is only 1 of many reasons why electron is bad.

A hundred times this; 500-1000mb of idle memory usage by a chat client is patently silly.

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

#130

Post by danShumway »

comex wrote: post #80
danShumway wrote: post #58

Earlier quoted context omitted.

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…

> 4. A few good, Open Source native ports already exist, and people are just unaware of them. Native GUI clients: - Ripcord: https://cancel.fm/ripcord/ - Wey: https://github.com/yue/wey ("written in Node.js with native UI powered by the Yue library") - Volt: https://volt-app.com IRC bridges (allow using Slack from native IRC clients): - wee-slack: https://github.com/wee-slack/wee-slack - irc-slack: https://github.com…

Nice -- I assumed there were at least one or two, didn't know there were so many!

Once Riot and Matrix pick up steam, I suspect the Electron debate will be even less of a real issue, since you can pretty safely build a native client for Matrix and know for sure that nobody on the corporate side is going to get annoyed and tell you stop.

Post reply on HN