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

81–90 of 408 posts

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

#81

Post by basch »

Despegar wrote: post #65

Slack is eventually going to write native apps once they realize that productivity software shouldn't be developed like an ad product from Google. It will take Teams winning because it gets included in the Office 365 subscription for several quarters before they come to the realization that they need to compete on user experience.

an electron app (teams) beating them will lead them to the conclusion that they shouldnt use electron?

I mean, I agree, losing mass marketshare SHOULD lead to a major shakeup on trajectory, and competing on desktop user experience would be a logical next step. But... back to the first sentence of this comment.

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

#82

Post by mtarnovan »

nottorp wrote: post #19
pwinnski wrote: post #13

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.

Not sure why you were downvoted. I agree with this definition. This is the main point of the whole discussion about the Slack client being bloated, consuming huge amounts of memory (and sometimes CPU) etc.

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

#83

Post by acemarke »

fooddood wrote: post #72
acemarke wrote: post #67

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

Isn't the common sentiment now that Redux is no longer considered a must-have for all greenfield projects? Also aren't communication apps a perfect use case for Redux due to the need to have events from multiple sources happen in a single store in a linear order?

That's part of what I was getting at, and what I talk about in the first couple links.

Lots of folks have used Redux because they were _told_ they "need" to use it. That's always been overkill. And, yes, there are plenty of other viable alternatives that overlap Redux's capabilities in various ways (Apollo, MobX, React context, etc).

So sure, it's not a "must-have", because you should _always_ evaluate tools and determine what's really appropriate for your use case rather than just blindly using something.

But, at the same time, Redux is still very widely used (~50% of React apps), and not going away. So, there's a big difference between "not an automatic must-have" (which is true) and "dead/dying" (which is not).

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

#84

Post by dmitrygr »

danShumway wrote: post #58
mtarnovan wrote: post #9

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

The fact that nobody's gone out on their own and built a native client means at least one of four things is true: 1. Slack is too restrictive, and its API is too poorly supported for anyone to create a port. I find this unlikely, given that the API is extensively documented and that an Emacs port already exists, but maybe there are problems I'm not aware of. 2. Good native ports are actually a lot harder to build and…

5. how can I make $$$ from spending a few months writing a native client? Slack can cut me off anytime they get annoyed with me. So even if my client is better, they can decide i am a threat and cut me off.

Never build your future on someone else's platform.

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

#85

Post by notatoad »

ch_sm wrote: post #29
notatoad wrote: post #22

Earlier quoted context omitted.

No company has infinite resources. Maintaining native mac and windows apps to appease the few people who have an irrational hatred of electron doesn't make good business sense when those resources could be going work that actually improves their product in a meaningful way.

not irrational. the performance problems can be measured and are noticeable in everyday use.

how can you measure the performance difference between an app that exists and one that doesn't?

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

#86

Post by Despegar »

basch wrote: post #81
Despegar wrote: post #65

Slack is eventually going to write native apps once they realize that productivity software shouldn't be developed like an ad product from Google. It will take Teams winning because it gets included in the Office 365 subscription for several quarters before they come to the realization that they need to compete on user experience.

an electron app (teams) beating them will lead them to the conclusion that they shouldnt use electron? I mean, I agree, losing mass marketshare SHOULD lead to a major shakeup on trajectory, and competing on desktop user experience would be a logical next step. But... back to the first sentence of this comment.

Teams is winning because it's being bundled with Office 365. The business model and distribution lets them compete effectively with an inferior product. Slack doesn't have that luxury.

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

#87

Post by penagwin »

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.

In my experience at least ~100/150MB will be electron's minimum anyway, certainly impressive what they've done but I think they've basically hit bedrock unless they either improve electron itself or switch to something different.

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

#88

Post by ebg13 »

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?

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

#89

Post by notatoad »

montag wrote: post #51
notatoad wrote: post #22

Earlier quoted context omitted.

No company has infinite resources. Maintaining native mac and windows apps to appease the few people who have an irrational hatred of electron doesn't make good business sense when those resources could be going work that actually improves their product in a meaningful way.

They are already maintaining apps for each platform. The question is whether the shared part is written in C++ vs. JavaScript.

>The question is whether the shared part is written in C++ vs. JavaScript.

also, whether the shared part is 98% of the code or 50% of the code.

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

#90

Post by mvanbaak »

danShumway wrote: post #58
mtarnovan wrote: post #9

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

The fact that nobody's gone out on their own and built a native client means at least one of four things is true: 1. Slack is too restrictive, and its API is too poorly supported for anyone to create a port. I find this unlikely, given that the API is extensively documented and that an Emacs port already exists, but maybe there are problems I'm not aware of. 2. Good native ports are actually a lot harder to build and…

I use weeslack and matterbridge. Weeslack is a python plugin for the irc client weechat. Matterbridge syncs slack channels with other services like telegram and irc.
Post reply on HN