Live data from Hacker News

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

medium.com

131–140 of 408 posts

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

#131

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

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

#132

Earlier quoted context omitted.

The hack I used to use to inject CSS into the app for a dark theme is no longer viable. So that changed.

I got the dark theme to work. Would you be interested in a write up?

I would! I imagine others would be as well.

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

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

Their comment had nothing to do with IRC. It was comparing two chat clients and how Slack's Electron version is much worse than a native version.

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

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

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

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

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.

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

#136

Earlier quoted context omitted.

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…

Their comment had nothing to do with IRC. It was comparing two chat clients and how Slack's Electron version is much worse than a native version.

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

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

#138
post #19

Earlier quoted context omitted.

Electron makes it a desktop app. That part has not changed.

Just because you don't see the browser it doesn't mean it's not still there. No, js/html "applications" are not desktop apps, they're web pages. Doesn't matter how you hide it.

Correct! I don't get why people are scared of writing native applications. It's not that hard.

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

#140

Earlier quoted context omitted.

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

Except in this metaphor, in terms of features, performance, and sheer quality of experience, a Rolls Royce would be something like LimeChat, and Slack is a Ford Pinto

Truly spoken as a programmer, whose ultimate chat experience is text in a terminal. Why would anyone want GIFs or images in their chat app? Crazy people...
Post reply on HN