Live data from Hacker News

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

medium.com

111–120 of 408 posts

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

#111
post #32

I will consider this benchmark vindication both for myself and the times I've had to argue as to why Electron isn't the issue, as well as the commentator from many moons ago who worked at Slack, dropped in here and explained why Electron wasn't the problem (rather, poor engineering on Slack's part was), and then was ripped to shreds over it. In fact I'm sure this comment will bring out native fanatics in force. At an…

It’s little more than a simple IRC client that consumes 250-500 megs of RAM. I wouldn’t take any victory laps over the supposed “efficiency” of Electron here.

Yeah, and a Rolls Royce is little more than a Honda with worse miles per gallon.

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

#112

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

I internalize this as every rewrite is a race to feature parity. Keep your races small and be prepared to call them off and devote energy elsewhere.

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

#113

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

Thank you! I read the first sentence and had to speak "bullshit" out loud. Sometimes rewriting something feels so good. Especially after some time has past and you are still in the process of learning. You apply all the things you have learned and your are amazed how much better it has become.

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

#114
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…

I don't really understand the hacker love for IRC. It's always been hard to figure out what level of encryption you can expect, what plugins are supported on what clients, using it from multiple devices was never a good experience, you miss any messages sent while your pc was off, very poor support for searching server history for messages with certain text, sending files can be confusing, etc. Having a snappy client is cool but it'd be cooler if it supported half the modern features people enjoy when using chat.

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

#115
post #110

Earlier quoted context omitted.

That's nice for them, but no matter what OS you're on the desktop client is probably crappier than loading up the webpage, with the one upside of giving you a separate icon in the dock and app switcher. Even with the performance improved, the "stuff the whole app in one web view" implementation is still showing. Clearly this isn't an Electron limitation; VS Code handles multiple windows just as well as any other text…

> no matter what OS you're on the desktop client is probably crappier than loading up the webpage I don't see how it could ever be worse than the webpage. And it gives you nice perks like notification badge integration, which for me personally is essential.

My web browser has windows and tabs and lets me open Slack in multiple places if I want to see more than one view of Slack at the same time.

I usually don't need to do that, but when I do it's annoying that the desktop client prevents it.

It's fine that my phone doesn't let me open two text conversations at once since that's all the space it has, but on a computer with a 24+ inch screen and multiple virtual desktop spaces with different sets of tasks, it's a pointless limitation.

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

#116

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

Thank you! I read the first sentence and had to speak "bullshit" out loud. Sometimes rewriting something feels so good. Especially after some time has past and you are still in the process of learning. You apply all the things you have learned and your are amazed how much better it has become.

Rewriting things always "feels so good", which is why people offer up the advice not to do it.

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

#117
post #11

How about a native client? I think it's safe to assume that Slack has the resources for this.

No matter the available resources, maintaining three separate desktop apps as well as a web app would mean fewer features and more bugs across the board. And Linux would probably be left on Electron (with less support attention), if not abandoned altogether.

I think fewer features can be a very good thing actually.

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

#118

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

+1 on all fronts. Rewrites/big refactors can be tremendously helpful 3-4 years in a big project's life. At least on the stuff I've worked on, that's around the time that accumulated tech debt has built up and the problem domain the we were hoping to solve is now well understood with production traffic.

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

#119

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

Point 3 seems to redefine “rewrite” as “partial rewrite”, which is essentially in the spirit of “never rewrite the [whole] code[base] from scratch”. Am I missing something?

Edit: Clarified quote of original rule.

Post reply on HN