" 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.
When a rewrite isn’t: rebuilding Slack on the desktop
231–240 of 408 posts
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#232Re: When a rewrite isn’t: rebuilding Slack on the desktop
#233Earlier 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
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#234Earlier 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.
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
#235Earlier 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
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#236"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.
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…
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#238For 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…
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…
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
#240Earlier 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.
And you, without knowing all the product requirements and technical constraints, know this exactly how?