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

161–170 of 408 posts

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

#161

Post by somethingnot »

msbarnett wrote: post #145
somethingnot wrote: post #140

Earlier quoted context omitted.

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

Truly spoken like someone who isn’t aware that most IRC clients, including LimeChat, will happily display images, including gifs, but for some reason feels confident and qualified enough in their uninformed opinion to be belligerent about it on the internet.

Funny how a google images search for limechat fails to find a single screenshot with inline images. But I'll take your word for it.

I guess that settles it. People will dump Slack and Discord on mass and move to the amazing IRC clients like LimeChat which are so much more efficient. it's well known that the number one thing people look at when choosing software is how efficient they are. Nobody cares about looks or features, just about CPU cycles.

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

#162

Post by BinaryIdiot »

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

Depends on the problem you're talking about. Slack made their memory usage considerably worse due to poor programming so that's obviously an issue. But that also doesn't negate the other issues electron brings.

Personally I would have used those years of development time to go native but it is what it is.

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

#163

Post by rob74 »

Hmmm... trying to optimize their Electron app is nice, but how about a real desktop app instead of a heavyweight browser engine masquerading as one? Would be really nice, especially for an app you have to have running in the background the whole time. But the chances for that are slim, I'm afraid...

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

#164

Post by atesti »

chinhodado wrote: post #124
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…

There's this classic article on the topic: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Ironically, FogBugz will be rewritten now: https://www.fogbugz.com/blog/fogbugz-rebuild-spec/

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

#166

Post by sagichmal »

bengale wrote: post #44
sagichmal wrote: post #21

Earlier quoted context omitted.

Past a certain point, the downsides of Electron outweigh the downsides of native apps. We've crossed that Rubicon years ago.

If this was the case we wouldn't see so many Electron apps. You just don't perceive enough of the upsides to see why the decisions are being made.

You're right, I, a user, don't perceive any of the upsides.

The upside that keeps getting paraded around is that it's a huge boon for product velocity. But that's just objectively false because Slack-the-product hasn't meaningfully changed in years.

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

#167

Post by qudat »

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…

> For me the gold standard of Chat applications is always going to be mIRC.

For you ... for me, mIRC is difficult to use, understand, and overall not nearly as aesthetically pleasing as slack.

Not to mention mIRC is missing a ton of features that slack has which specifically makes it better suited for businesses. Push notifications and chat history to name a few.

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

#168

Post by ex3ndr »

DaiPlusPlus wrote: post #74
Klonoar wrote: 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.

iTerm2 eats 150mb+. Any cocoa app use that much of memory. App Store is 500mb just after launch.

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

#169

Post by asark »

harryh wrote: post #135
DaiPlusPlus wrote: post #74

Earlier quoted context omitted.

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.

Those memory-bloat apps are never, never only memory hogs. They always come with an outsize hit to general system responsiveness, always have UI lag, and so on. These days almost all of them are webtech junk. I still have a few Java programs with that problem —I've been reading "it's in your head, here's a proof that it can't be as bad as you say" for like 20 years now and those folks continue to be wrong in practice—but webtech's even worse.

Which makes perfect sense. If you're operating on more memory than should be necessary you're gonna be burning a lot more processor/battery than is reasonable, too.

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

#170

Post by jscheel »

acemarke wrote: post #100
jscheel wrote: post #76

Earlier quoted context omitted.

Thanks for the articles! We've been using Redux since August of 2016 at Groove. For us, we've found that Redux makes sense when you have state that needs to be shared. If you are dealing with some specific, tightly coupled component state, it sometimes makes sense to keep that particular piece of state local to the component (at least for our use-case). The biggest issues we've run into during our time with Redux hav…

Yep. The Redux "Three Principles" docs page [0] emphasizes the "single source of truth" aspect. It's a good selling point, but has unfortunately led to a lot of folks interpreting that as "you _must_ keep _everything_ in Redux". (Doing so is a valid design decision, and I've certainly talked to folks who deliberately did that to make everything trackable and time-travel-able. But, most UI state probably doesn't need…

Awesome, I'll hit you up in Discord.
Post reply on HN