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

181–190 of 408 posts

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

#181

Post by dmitriid »

stephenr wrote: post #122
notatoad wrote: post #85

Earlier quoted context omitted.

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.

Very few prior apps did what Slack is doing [1] And there are not that many actual competitors if you start counting them.

[1] It's still strange to me that many people compare Slack to IRC and XMPP and complain that they were doing all the same things, why have people abandoned them. Even though they (and especially the clients) were doing (or capable of doing) just a small fraction of what Slack is doing.

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

#182

Post by SkyMarshal »

stephenr wrote: post #73
johnzim wrote: post #66

Earlier quoted context omitted.

Slack also grew out of the team that made Glitch https://en.wikipedia.org/wiki/Glitch_(video_game) That core team therefore had a lot of frontend web dev experience. It made sense that they'd stick to their strengths

The performance and resource usage of slack both on the desktop and in a browser indicates that “front end code” is not their strength.

Creating a web app with a multi-billion dollar valuation indicates it is their strength. Who cares about a little superfluous memory usage compared to that.

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

#183

Post by DaiPlusPlus »

harryh wrote: post #135
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.

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.

8GB - minus OS load gives you about 5-6GB to play with.

The problem isn’t with Slack itself - as more and more desktop software run on Electron then with 8GB of RAM you can only have a handful of instances open simultaneously before you get performance- crushing disk paging.

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

#184

Post by kllrnohj »

harryh wrote: post #135
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.

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.

Just because there's enough resources for it doesn't mean it was a good use of those resources.

Why should it be reasonable for displaying a few megs of text & maybe a dozen megs of images to take 250MB+ of RAM? What is the rest of that memory usage, and why is it loaded? CPUs don't like executing code that's not in cache, so hopefully it's not code. And if it's not code, what is it? Figure a few dozen MB for the graphic buffers, but where's the other 100MB+ gone?

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

#185

Post by msbarnett »

somethingnot wrote: post #161
msbarnett wrote: post #145

Earlier quoted context omitted.

Truly spoken like someone who isn’t aware that most IRC clients, including LimeChat, will happily display images, including gifs, but for some reason feels confident and qualified enough in their uninformed opinion to be belligerent about it on the internet.

Funny how a google images search for limechat fails to find a single screenshot with inline images. But I'll take your word for it. I guess that settles it. People will dump Slack and Discord on mass and move to the amazing IRC clients like LimeChat which are so much more efficient. it's well known that the number one thing people look at when choosing software is how efficient they are. Nobody cares about looks or f…

If people cared about looks or features, Slack certainly wouldn’t come out on top.

No, what people care about are primarily network effects. They'll use whatever someone in the company decided to use (frequently Slack because it’s always been Slack since someone back in 2013 decided it was the hip choice, before it even had a desktop client), and they’ll put up with whatever dogshit client they’re served, because it’s out of their hands.

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

#186

Post by thecopy »

harryh wrote: post #172
msbarnett wrote: post #155

Earlier quoted context omitted.

Too high compared to similarly featured (or even more full featured) programs built on other technologies. 3% on an Electron chat app here, 5% on an Electron text editor there, and pretty soon you’ve managed to replace what could’ve been several apps with small memory footprints plus several gigs of efficient file caching in a users’ RAM with just a few bloated programs crowding out the cache, and made their entire m…

If someone is running so much stuff that an app (or a few apps) using ~250MB of ram instead of ~100MB (or whatever) of ram is a huge problem they can easily spend $200 or so for an extra 8GB of ram. Ram is cheap. Usage at this scale just doesn't matter to the vast majority of users.

My RAM is soldered on.

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

#187

Post by SkyMarshal »

harryh wrote: post #172
msbarnett wrote: post #155

Earlier quoted context omitted.

Too high compared to similarly featured (or even more full featured) programs built on other technologies. 3% on an Electron chat app here, 5% on an Electron text editor there, and pretty soon you’ve managed to replace what could’ve been several apps with small memory footprints plus several gigs of efficient file caching in a users’ RAM with just a few bloated programs crowding out the cache, and made their entire m…

If someone is running so much stuff that an app (or a few apps) using ~250MB of ram instead of ~100MB (or whatever) of ram is a huge problem they can easily spend $200 or so for an extra 8GB of ram. Ram is cheap. Usage at this scale just doesn't matter to the vast majority of users.

Agree in principle, but available Ram real estate (slots) is limited, esp in mobile.

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

#188

Post by ben509 »

harryh wrote: post #172
msbarnett wrote: post #155

Earlier quoted context omitted.

Too high compared to similarly featured (or even more full featured) programs built on other technologies. 3% on an Electron chat app here, 5% on an Electron text editor there, and pretty soon you’ve managed to replace what could’ve been several apps with small memory footprints plus several gigs of efficient file caching in a users’ RAM with just a few bloated programs crowding out the cache, and made their entire m…

If someone is running so much stuff that an app (or a few apps) using ~250MB of ram instead of ~100MB (or whatever) of ram is a huge problem they can easily spend $200 or so for an extra 8GB of ram. Ram is cheap. Usage at this scale just doesn't matter to the vast majority of users.

Of course, if Slack thought this were true, they wouldn't have bothered with this rewrite.

Obviously no PM is going to tell customers, "just spend $200 for another 8GB of RAM to run our chat software."

> Usage at this scale just doesn't matter to the vast majority of users.

The usage model is that it's on all the time. So if it's draining batteries, causing paging or otherwise slowing things down, people are going to quit Slack, thus defeating the immediacy of communication, thus defeating the point of running Slack.

And Slack becomes powerful when it can be required by a workplace, which is their business model. This means the "vast majority" isn't enough at any given company.

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

#189

Post by pjmlp »

somethingnot wrote: post #161
msbarnett wrote: post #145

Earlier quoted context omitted.

Truly spoken like someone who isn’t aware that most IRC clients, including LimeChat, will happily display images, including gifs, but for some reason feels confident and qualified enough in their uninformed opinion to be belligerent about it on the internet.

Funny how a google images search for limechat fails to find a single screenshot with inline images. But I'll take your word for it. I guess that settles it. People will dump Slack and Discord on mass and move to the amazing IRC clients like LimeChat which are so much more efficient. it's well known that the number one thing people look at when choosing software is how efficient they are. Nobody cares about looks or f…

Some of us would love to do it, but job and customers aren't there.

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

#190

Post by pjmlp »

s_y_n_t_a_x wrote: post #69
bfrog wrote: post #60

Well there goes my last hope of ever getting a native slack client in my lifetime. I miss hipchat often. They had enough sense to make the client native.

Not really, they could use React Native, even for desktop.

Actually that would be much better.

There is hope though, React Native for Windows team did a presentation showing how bad Electron resource usage was versus their React Native for Windows prototype.

So maybe they could do some advocacy to the VSCode team and start a migration movement.

Post reply on HN