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

201–210 of 408 posts

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

#201

Post by [deleted] »

paxys wrote: post #134
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…

Your third point is arguing against the premise. A "partial rewrite" isn't a rewrite. That's the entire point.

[deleted]

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

#202

Post by merb »

charrondev wrote: post #154
guessmyname wrote: post #96

Earlier quoted context omitted.

HipChat was originally built using Adobe Air (2012) [1]. Then they switched to QT using WebView (2013) [2]. Then they created Stride using Electron (2017) [3] Finally they created a partnership with Slack (2018) [4]. [1] https://www.engadget.com/2013/02/14/hipchat-ditches-adobe-ai... [2] https://techcrunch.com/2013/02/14/with-3500-paying-customers... [3] https://techcrunch.com/2017/09/07/atlassian-launches-stride-...…

Thanks for the context! I was using from 2017 -> Feb 2019 when we migrated to slack. It definitely had a webview feel similar to slack. I never particularly noted any memory issues. I haven't noticed any with slack either though. For me my top memory consumers end up being: 1. Docker (web dev servers) 2. Chrome 3. Firefox 4. VSCode 5. 1Password 6. Spark 7. Sublime Text Even at the bottom of the list they are using 20…

I don't know which 1 password you are using but my 1password uses two accounts and sits at below 100mb. lower than slack/spark/vscode and many more apps.

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

#203

Post by pas »

harryh wrote: post #175
asark wrote: post #169

Earlier quoted context omitted.

Those memory-bloat apps are never, never only memory hogs. They always come with an outsize hit to general system responsiveness, always have UI lag, and so on. These days almost all of them are webtech junk. I still have a few Java programs with that problem —I've been reading "it's in your head, here's a proof that it can't be as bad as you say" for like 20 years now and those folks continue to be wrong in practice…

I've been using Slack on the desktop daily since the alpha version. I've never found it to have UI lag. I honestly think that most people us use phrases like "webtech junk" are offended on principle and not because of any measurable difference that matters to regular users.

I use it on the desktop too. And it is slow. Slow to start, slow to load channel data. Slow to appear after alt-tab, and so on.

I think it is because it expires caches left and right, loses track of events, or I have no idea what else could be going on on a PC with 16GB RAM (plenty of it free) and stable Internet connection.

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

#204

Post by jrockway »

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.

Low end desktops come with a gig of RAM. A $35 Raspberry Pi is what "low end" really is.

While 250MB is a big chunk... I think it's actually okay, even in this extreme case.

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

#205

Post by nameismypw »

SkyMarshal wrote: post #182
stephenr wrote: post #73

Earlier quoted context omitted.

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.

Developers who respect their work, for one.

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

#206

Post by Klonoar »

seandougall wrote: post #200
ex3ndr wrote: post #168

Earlier quoted context omitted.

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

> Any cocoa app use that much of memory. What gives you that idea? Lots of apps have cruft, but that's nothing to do with Cocoa. A "Hello, world!" in Cocoa uses around 13 MB, and the application bundle weighs in at 79 kB. The fact that Electron uses a bare minimum of over 100 MB just to get an application running is a source of some understandable consternation.

His point is, actually, quite valid. By the time you stop and rebuild all the image caching/media pieces, you'll end up with a hefty amount of memory usage too - Telegram (not the Qt one, the Cocoa one) will regularly climb up to 200ish MB if I have a media-heavy chat going.

People have skewed ideas of what's doable in memory constraints in 2019 for the feature sets that customers tend to expect.

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

#207

Post by msbarnett »

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.

Aside from the obvious issue that a ton of devices don’t have user upgradable RAM, are we really this comfortable with feeding constant consumerist abandonment of old devices through our own sheer laziness as developers?

“It only uses 8% of 8GB of RAM. If that’s an issue consumers can buy more RAM or throw away their devices and buy new ones” is soon phrased as “It only uses 8% of 16GB of RAM. If that’s an issue consumers can buy more RAM or throw away their devices and buy new ones” and soon after etc, etc

At some point, preferably before we start saying “it’s just half a terabyte of RAM to run a chat app”, we may want to step back and question this circular justification for ever increasing bloat and ask ourselves when enough is enough. There’s been no real gain in functionality in the past 10-20 years of chat app churn, just an enormous explosion in RAM and CPU requirements.

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

#208

Post by bmurphy1976 »

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, you can dork around in the font preferences dialog and change some things, but there is no option to scale all of the UI (UI => Scale => 120%). It ends up being a hodgepodge of unreadable small text mixed with reasonably sized by but poorly styled and colored larger text that's nearly as hard to read because of the lack of space separating elements. Of course everything gets more crowded when you increase the size, instead of doing what it should do and also increasing the space between elements to let everything breath.

In an Electron app, I can Ctrl-+, Ctrl-+ and everything looks great. I have yet to find a single native app that I use regularly where this isn't an issue. The only ones that comes close (no surprise here) is Sublime Text.

These problems just don't happen with Electron apps. Electron technology may be slower than native, but it sure nails UI scaling. I'll take a UI I can actually see over one that runs more efficiently any day.

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

#210

Post by s_y_n_t_a_x »

ergothus wrote: post #150
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…

Incremental rewrites (aka refactoring) is best, but sometimes that's just not viable, which is where I feel conventional wisdom breaks down. If your code is trying to get updated, you can usually refactor. If your code is having a paradigm shift, it's likely any incremental rewrite will take more time and have more duplication without benefit for far too long to be successful.

Incremental rewrites !== refactoring.

You can rewrite portions of the app and embed the older components in the new app until you rewrite them as well.

Post reply on HN