Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

101–110 of 408 posts

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

#101

Post by somethingnot »

throwaway66666 wrote: post #23
mtarnovan wrote: post #9

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

Nobody has the resources for that. Some companies make OSes, and some companies send rockets to space. Those feats are also powered by thin wrappers over electron. /s People seem to forget that C++ and opengl is cross-platform. And there are projects far bigger than slack, like ffmpeg and OpenCV that have existed for decades, always had very fast development cycles, with only a subset of the funding and money that Sl…

> People seem to forget that C++ and opengl is cross-platform

OpenGL is dying. It's already deprecated on MacOS.

https://appleinsider.com/articles/18/06/04/opengl-opencl-dep...

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

#103

Post by mcguire »

"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 same time you are rewriting. Try to keep the friction down to a manageable level.

3. Incremental rewrites are best. Pick part of the project, rewrite and release that, then get feedback while you work on rewriting the next chunk.

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

#104

Post by wlesieutre »

_bxg1 wrote: post #59
wlesieutre wrote: post #54

Earlier quoted context omitted.

The upsides are for the companies shipping it, the downsides are for the users. So it's not a surprising outcome.

Tell that to people who want to use modern services on a Linux workstation

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

Slack's desktop client is basically "It's a web browser except worse and with the URL bar hidden." Since chat requires an internet connection and it's not like Slack's desktop version launches particularly fast, I'm not sure that it does anything better than using a browser.

We'll see if they support multiple instances on iOS 13. If they do, maybe we can get a Mac version based on that for something closer to native desktop behavior.

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

#105

Post by mh- »

ebg13 wrote: post #88

In their side-by-side memory usage comparison, what the hell is happening on the left at 6 teams that isn't happening at 5 teams and happening at 3 teams that isn't happening at 2 teams? What the is happening on the right at 6 teams that isn't happening at 5 teams?

They're buckets, it's 6 or more teams ("6+") not 6.

The only one that doesn't make sense to me is _2 teams_. Unless they had some specific hack to reuse processes for a 2nd team, how can the incremental memory usage of that 2nd team be almost nothing?

Thinking about it, though- separate teams were lazily loaded and the usage behaviors of people with different numbers of teams probably varies substantially enough to cause these artifacts. e.g. I imagine this is "3-5 teams logged in" not "3-5 teams actively loaded".

(disclaimer: I don't work for Slack, just speculating.)

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

#106

Post by zhobbs »

ebg13 wrote: post #88

In their side-by-side memory usage comparison, what the hell is happening on the left at 6 teams that isn't happening at 5 teams and happening at 3 teams that isn't happening at 2 teams? What the is happening on the right at 6 teams that isn't happening at 5 teams?

Also curious about the 3 vs 2 on the left. For 6, it says 6+, so maybe that is a mean that could include outliers with tons of active workspaces.

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

#107

Post by tptacek »

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…

#3 is in fact what they did, and what this post is mostly about, though their releases were apparently internal.

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

#108

Post by leeoniya »

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.

100%. rewriting all layers simultaneously is the first step to never finishing.

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

#109

Post by tonyarkles »

me551ah wrote: 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…

Not mIRC, but I run x-chat and Slack side-by-side on a daily basis. Wholly different experience... I don’t think I’ve ever had to kill x-chat for pegging a CPU and killing my battery :)

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

#110

Post by _bxg1 »

wlesieutre wrote: post #104
_bxg1 wrote: post #59

Earlier quoted context omitted.

Tell that to people who want to use modern services on a Linux workstation

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.

Post reply on HN