Live data from Hacker News

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

medium.com

231–240 of 408 posts

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

#231
post #134

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

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

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

#232
There's a lot of discussions that Slack should go for a full native application. Yes memory/CPU usage would be much smaller but then again this cross-platform maintenance hell begins. You can look at Skype's example it didn't end well, Linux version was lagging totally behind, also Mac client wasn't up to date and now Skype also released web client :D.

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

#233
post #134

Earlier quoted context omitted.

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

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

But that's not what Joel was arguing against when he first wrote the article against rewrites.

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

#234
post #190

Earlier quoted context omitted.

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.

This rewrite is the first step of that, going from jQuery to React.

React Native for Windows is ready for production, it powers their new Skype. It's being rewritten right now from C# to C++ for better performance in their vnext branch.

You have the option to use react-native-web (Twitter's way) to run your React Native app on the web, or use ReactXP (Microsoft's way).

React Native Web forks React Native. ReactXP wraps React and React Native. Two different approaches. Personally I prefer ReactXP because React Native Web will always be too far behind React Native. It's easier for ReactXP to update. Both projects have major backers and power major products.

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

#235
post #134

Earlier quoted context omitted.

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

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

Literally referenced in the article

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

#236
post #6

"We acknowledge that nobody should ever rewrite from scratch... but after five years we're rewriting from scratch because we know better."

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.

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

#237

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

[deleted]

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

#238
post #20

For me the gold standard of Chat applications is always going to be mIRC. It supports a ton of plugins, consumes 10-50mb of memory and little to no CPU. You could be connected to multiple servers and channels with DCC scripts running and you still wouldn't notice that it's even running. Even though Slack is using react now, they are still using electron under the hood. Which means it can never match the snappiness of…

Yes! This 1000x this! I cut my teeth on mIRC scripting. Frustrating and enjoyable at the same time.

I've since moved to IRSSI and others, but you are correct about memory/CPU usage and functionality.

Every single '$new-thing' like Slack makes the interaction WORSE, instead of improving it. I wish more SV superstars were greybeard hackers.

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

#239

" 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 are best

That's perfectly compatible with the conventional wisdom you claims wrong, which, again, was “you should never rewrite your code from scratch” [emphasis added]

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

#240

Earlier quoted context omitted.

The native client they were referring to was mIRC, which does much less than Slack does. A better comparison might be Discord, which performs much better than Slack and is also written in Electron. VSCode, written in Electron, performs much better for me than Visual Studio (a native app), but I wouldn't use that as proof that Electron is faster than native apps because Visual Studio does so much more

The major differences I can think of off the top of my head are threading, reactions, voice chat, and history. Voice chat is the only one that should use significantly more resources than mIRC.

> Voice chat is the only one that should use significantly more resources than mIRC.

And you, without knowing all the product requirements and technical constraints, know this exactly how?

Post reply on HN