When a rewrite isn’t: rebuilding Slack on the desktop • Hacker News Board

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

#281

Post by saagarjha » Mon, Jul 22, 2019, 10:47 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.

The "Cocoa" Telegram is not really Cocoa at all :/

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

#282

Post by bdcravens » Mon, Jul 22, 2019, 10:50 PM UTC

pwinnski wrote: post #236

bdcravens wrote: post #26

Earlier quoted context omitted.

It’s an iterative rewrite, which is how you should do it. “Rewrites are bad” refers to a blank slate and reimplementing.

I didn't choose the framing, they did. Here are the first sentences of the first two paragraphs: > Conventional wisdom holds that you should never rewrite your code from scratch, and that’s good advice. > Still, software codebases have life spans.

Yes, those sentences set up the rest of the article, establishing the thesis: Those two sentences are true, and not necessarily at odds with one another. The author spends the rest of the article explaining this, and how they accomplished it.

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

#283

Post by paulddraper » Mon, Jul 22, 2019, 10:51 PM UTC

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.

> Too high for what?

Too high for an app that runs continuously.

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

#284

Post by saagarjha » Mon, Jul 22, 2019, 10:52 PM UTC

bmurphy1976 wrote: post #217

wmf wrote: post #214

Earlier quoted context omitted.

Or you could change your screen resolution?

That's a terrible solution. I chose my monitor specifically because it's HIDPI, not high resolution. It's easier on my eyes to read smoothly rendered text in HIDPI than jaggedly rendered text all day long. Changing the resolution subverts that.

If you're using macOS, have you tried changing the screen resolution? On HiDPI monitors it doesn't produce "jaggedly rendered text" at all (in fact, Apple ships a number of laptops with this as the default configuration…)

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

#285

Post by GuB-42 » Mon, Jul 22, 2019, 10:54 PM UTC

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.

My opinion is that there is no low threshold for RAM use. If you can go down from 200kB to 100kB, that's still a win, even in a 32GB machine.

The reasons:

- Cache. RAM may be >8GB but the CPU L1 cache is just 64kB. And L1 cache is about 100 times faster than RAM. From my experience, proper cache management is by far the most important low level optimization, and most of it can be archived by just using less RAM.

- What are you doing with all that RAM? 250MB in absolute terms is huge. The entire Harry Potter series is around 5MB uncompressed. For that size you can also have a 1080p fullscreen RGB image, uncompressed. What it means is that unless you are working with large datasets, these 250MB represent a huge amount of stuff you don't control. Lots of moving parts with potential performance bottlenecks, security issues, etc...

- Every byte your app is using is one less byte for your system caches. Wasting RAM makes your whole system go slower.

- Finally, an ethical argument. Your chat app will run continuously on millions of PCs. On that PC are libraries, kernel code and frameworks where people worked hard squeezing every bit of performance they could. Saving energy and making your apps run to their full potential. For me, a background app made by a company the size of Slack have a duty to be as light as possible, as not to interfere with the actual work people are doing on their machine.

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

#286

Post by saagarjha » Mon, Jul 22, 2019, 10:56 PM UTC

snowwrestler wrote: post #49

sagichmal wrote: post #21

Earlier quoted context omitted.

Past a certain point, the downsides of Electron outweigh the downsides of native apps. We've crossed that Rubicon years ago.

Pretty sure we crossed the Rubicon in the other direction, as it was basically the popularity of Electron apps that forced Microsoft to abandon their own browser rendering engine in favor of Chromium. If you had come to me 10 years ago and said "Microsoft will drop their browser and use Google's code," I absolutely would not have believed you.

> it was basically the popularity of Electron apps that forced Microsoft to abandon their own browser rendering engine in favor of Chromium

I don't see how this has anything to do with the point here (browser engines are not normal applications…) or if it's even true.

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

#287

Post by mcguire » Mon, Jul 22, 2019, 10:58 PM UTC

wvenable wrote: post #219

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…

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

Changing languages or platforms is a frequent cause for a rewrite. (Especially if the old one is Modperl 1.)

On the other hand, if you need to refactor the database schema, don't rewrite the code. Just do the minimum modifications to keep the app working.

Just don't do both at once.

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

#288

Post by mcguire » Mon, Jul 22, 2019, 10:58 PM UTC

paulddraper wrote: post #280

wvenable wrote: post #249

Earlier quoted context omitted.

"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. " -- Fred Brooks, The Mythical Man-Month Attempting a design re-write without changing the data structures will just result in the same design. And you can't change the data design without then having to change the code to match.

Exactly. If I'm not refactoring the underlying data structures....the refactoring isn't a very interesting/difficult one at all

That would kind of be the point.

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

#289

Post by Lazare » Mon, Jul 22, 2019, 11:00 PM UTC

wootie512 wrote: post #131

acemarke wrote: post #67

I know that popular opinion in the Twitterverse is that "Redux is dead", but I note that both Twitter and Slack just released major rewrites that use Redux heavily. I talked about Redux usage stats and comparison with other alternatives in my "State of Redux" talk at Reactathon earlier this year [0], and my post "Redux - Not Dead Yet!" also addresses some of these aspects [1]. Also, quick plug for our current focus.…

What is the goto for web if Redux is dead? I am not super knowledgeable about all the exact architectures, but I thought mobile was just starting to adopt the redux architecture vs MVP, MVVM, etc

I wouldn't say Redux is dead, but there are a number of alternatives. My team has switched from Redux to MobX for all new development, as the two libraries solve the same problems, and we find MobX a bit easier to work with for our specific use cases.

There's nothing wrong with Redux; we just found that Redux based code tended to have a fair bit of boilerplate, and it wasn't as easy to maintain code using Redux as we would have liked. Every dev team has to find the right place to draw the line on implicit versus explicit, magic versus verbose, convention versus configuration. No real right or wrong answers.

> I thought mobile was just starting to adopt the redux architecture

I don't think so, no. The Redux architecture (ie, reducers, actions, etc.) is fairly specific and not universally loved. I would say that people are starting to really grasp the importance of solving the problems that Redux solves, however.

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

#290

Post by [deleted] » Mon, Jul 22, 2019, 11:03 PM UTC

m463 wrote: post #266

kbenson wrote: post #231

Earlier quoted context omitted.

At some point a partial rewrite might become a complete rewrite. It depends. Ship of Theseus[1], etc. 1: https://en.wikipedia.org/wiki/Ship_of_Theseus

The easy way to fund a new military plane is: - remove one bolt and raise in the air - slide out rev 30 "parts" from beneath bolt - slide in rev 40 "upgrade parts" (fuselage, wings, engines, etc) underneath the bolt - fly "upgraded plane" without a lot of pesky 'new plane" studies Additionally, in parts of california, how to build a house: - find existing house - pick a wall - remodel everything except for that wall…

[deleted]