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

Post by dang » Mon, Jul 22, 2019, 9:07 PM UTC

pmarreck wrote: post #71

cat199 wrote: post #64

Earlier quoted context omitted.

interesting - they mention: "Slack connectivity is now available for testing. It's still pretty rough and missing a lot of features." any further insights here? could just try it myself, but slack is our key communication so getting more input would be great

can't comment on the original comment you made here https://news.ycombinator.com/item?id=20500181 because it's now flagged, so commenting here to state: There is a deafening irony in deplatforming a post arguing against deplatforming as a valid tactic. I hope it is not lost on the HN mods. ;)

Post by spookthesunset » Mon, Jul 22, 2019, 9:08 PM UTC

doc_gunthrop wrote: post #127

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.

Post by candiodari » Mon, Jul 22, 2019, 9:12 PM UTC

Klonoar wrote: post #206

seandougall wrote: post #200

Earlier quoted context omitted.

> 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.

Post by harryh » Mon, Jul 22, 2019, 9:13 PM UTC

msbarnett wrote: post #207

harryh wrote: post #172

Earlier quoted context omitted.

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 cons…

Post by wvenable » Mon, Jul 22, 2019, 9:18 PM UTC

coldtea wrote: post #244

wvenable wrote: post #219

Earlier quoted context omitted.

> Don't redesign the database schema at the same time you are rewriting. Chances are, that's the problem though. You have to re-write because your design is bad enough that it's necessary. The only time you'd re-write without changing the design is when changing languages or platforms.

You could do a rewrite that takes into account the bad old database schema, but doesn't repeat the wrong code design choices based on it. Then, when that's ready and stable and working with the existing schema, it's way easier to do a refactor and adapt to the new schema too.