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

301–310 of 408 posts

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

#301

Post by bhl »

floatingatoll wrote: post #263
DaiPlusPlus wrote: post #74

Earlier quoted context omitted.

I’m still skeptical. The memory usage chart from the article shows only a slight (10%?) improvement for single-workspace Slack clients, now at around 250MB. Yes, getting a 5+ workspace client down from ~800+MB to 300MB should be applauded - but the 250MB floor is still too high. I want to know what’s in the 250MB it’s still using.

I checked in Firefox and a given Slack uses 200+MB at load and then optimizes down to 140MB at runtime for a given Slack, of which ~60MB is JavaScript and ~80MB is page elements. So if those numbers carry over to Electron-Chromium, then it's 100MB of "I'm a browser" and 140MB of "I'm a webpage full of dynamic and objects". They certainly will not carry over precisely equally, but it puts some scope on it to consider.…

Why does slack and gmail use so much memory? It feels like it shouldn’t be an intensive process to display messages. Sidenote I don’t have much front end development besides basic web pages.

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

#302

Post by kup0 »

I was so hoping that they had dropped Electron.. but nope. At least they’re focusing on performance, but the achilles heel will always be there.

That said, as much as I dislike Electron, Microsoft has done a fine job with VSCode, so there are ways to do Electron “better”, even if the “best” Electron apps are still mediocre compared to native apps

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

#303

Post by cgh »

bmurphy1976 wrote: post #208
akstrfn wrote: post #153

Switching to ripcord on my laptop was a breath of fresh air. I always wonder why don't these companies develop proper desktop clients that dont wreck mid range laptops...

I never heard of ripcord. I just downloaded it and gave it a try. It suffers the same problems as every single native (non-electron) chat client I've ever used. Primarily it's hideous and you can't change the UI size uniformly. As an older dev who's eye sight isn't as good as it was 30 years ago when I started, it's getting harder and harder to use native apps because the default fonts are so goddamn small. Oh sure,…

From the Ripcord site:

"Features

- Not made from a web browser"

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

#304

Post by geofft »

rvz wrote: post #295
akstrfn wrote: post #153

Switching to ripcord on my laptop was a breath of fresh air. I always wonder why don't these companies develop proper desktop clients that dont wreck mid range laptops...

So Ripcord is created by one person in his spare time and it performs blazingly-fast and supports Slack whilst Slack's own client is maintained by tens if not hundreds of engineers and it still performs slower when joining more teams, consumes significant amounts of RAM and they create this blog-post about performance improvements whilst still using Electron. Understanding on why Slack is unable to create a performan…

I would love to see someone study this from a management / human factors perspective. I can think of all sorts of reasons why a team can't perform as well as an individual, ranging from the team needing to support more use cases than the individual does (onboarding via the web was super important for Slack's growth, I'd bet), everyone thinking it's not their place to rethink some major decision, some major decision being rethought but execution stuck in a team that isn't performing well, etc. And I'd be really curious, if you were in charge of a large organization, how to make it as effective as a single person (while still handling all the broad edge cases that large organizations do handle).

I suspect that "Why is Linux competitive with Windows" has many of the same answers, in the end.

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

#305

Post by harryh »

paulddraper wrote: post #283
harryh wrote: post #135

Earlier quoted context omitted.

250MB floor is still too high Too high for what? Low end desktops and laptops today come with 8GB of ram. Using ~3% of that for a chat app doesn't seem like a big deal.

> Too high for what? Too high for an app that runs continuously.

Nearly all users continuously run web browsers these days and they all consumer a lot more ram than slack.

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

#307

Post by mattl »

atesti wrote: post #164
chinhodado wrote: post #124

Earlier quoted context omitted.

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

Ironically, FogBugz will be rewritten now: https://www.fogbugz.com/blog/fogbugz-rebuild-spec/

FogBugz went from being ASP to ASP/PHP (Wasabi) to some version of .NET where they hosted it all.

I can’t believe FogBugz didn’t share any code with CityDesk.

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

#308

Post by gilgoomesh »

kup0 wrote: post #302

I was so hoping that they had dropped Electron.. but nope. At least they’re focusing on performance, but the achilles heel will always be there. That said, as much as I dislike Electron, Microsoft has done a fine job with VSCode, so there are ways to do Electron “better”, even if the “best” Electron apps are still mediocre compared to native apps

They're proud that they can operate in just 500MB of RAM for an app that shows scrolling lists of text.

The economics of RAM has changed somewhat but 1990s me is still appalled.

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

#309

Post by mattl »

ex3ndr wrote: post #168
DaiPlusPlus wrote: post #74

Earlier quoted context omitted.

I’m still skeptical. The memory usage chart from the article shows only a slight (10%?) improvement for single-workspace Slack clients, now at around 250MB. Yes, getting a 5+ workspace client down from ~800+MB to 300MB should be applauded - but the 250MB floor is still too high. I want to know what’s in the 250MB it’s still using.

iTerm2 eats 150mb+. Any cocoa app use that much of memory. App Store is 500mb just after launch.

Ah yes. I remember all those 8GB NeXTStations.
Post reply on HN