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

71–80 of 408 posts

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

#71

Post by pmarreck »

cat199 wrote: post #64
guessmyname wrote: post #42

Earlier quoted context omitted.

Ripcord [1] is a (native) desktop chat client for Slack and Discord written in C++ and QT. It was posted a few months ago [2] and I’ve been using it since then, it works great. [1] https://cancel.fm/ripcord/ [2] https://news.ycombinator.com/item?id=19617699

interesting - they mention: "Slack connectivity is now available for testing. It's still pretty rough and missing a lot of features." any further insights here? could just try it myself, but slack is our key communication so getting more input would be great

can't comment on the original comment you made here https://news.ycombinator.com/item?id=20500181 because it's now flagged, so commenting here to state: There is a deafening irony in deplatforming a post arguing against deplatforming as a valid tactic. I hope it is not lost on the HN mods. ;)

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

#72

Post by fooddood »

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?

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

#73

Post by stephenr »

johnzim wrote: post #66
throwaway66666 wrote: post #23

Earlier quoted context omitted.

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…

Slack also grew out of the team that made Glitch https://en.wikipedia.org/wiki/Glitch_(video_game) That core team therefore had a lot of frontend web dev experience. It made sense that they'd stick to their strengths

The performance and resource usage of slack both on the desktop and in a browser indicates that “front end code” is not their strength.

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

#74

Post by DaiPlusPlus »

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.

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

#75

Post by _bxg1 »

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.

What I've noticed is that much of the distaste with Electron apps has more to do with the idea of waste than with the actual practical implications. Programmers like things to be efficient and optimized. Electron sacrifices those traits in a couple of ways, in favor of actual productivity.

So "the downsides of Electron outweigh the downsides of native apps" when you're someone who patrols the task manager looking for things to be upset about. Your chat client - one of half a dozen applications you realistically have open - using 400MB of RAM on your 32GB workstation does not have a meaningful impact on your workflow. It's just offensive.

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

#76

Post by jscheel »

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

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 have been 1. not being atomic enough with our connected components (sometimes passing massive objects down the component tree instead of selecting what we need at each point), 2. running into leakiness in react-redux (such as function arity changing short-circuit caching behavior in the mapping functions, forgetting to invalidate components when using select factories, etc), and 3. not normalizing our store enough (which contributes to #1). As we continue to mature in Redux, we are slowly fixing #1 and #3 in our codebase. We are still sometimes getting bitten by weirdness in react-redux though. I'm not sure I have a solution, but I think there is still a lot of opportunity for improvement there. And not just in react-redux, in helping developers understand how to properly build performant redux-driven apps in general.

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

#77

Post by stephenr »

notatoad wrote: post #22
mtarnovan wrote: post #9

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

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.

Slack is the only web-app I’ve seen that routinely triggers the safari warning about its resource usage/affect on performance.

For years slack has been a resource pig on desktop and on the web. So what improvements are you imagining they’ve been working on? Chatting on the internet is hardly such a groundbreaking subject that it can’t be done efficiently.

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

#78

Post by msbarnett »

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…

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.

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

#79

Post by heavenlyblue »

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.

Google’s Ad product always had a desktop client called Adwords Editor.

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

#80

Post by comex »

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…

> 4. A few good, Open Source native ports already exist, and people are just unaware of them.

Native GUI clients:

- Ripcord: https://cancel.fm/ripcord/

- Wey: https://github.com/yue/wey ("written in Node.js with native UI powered by the Yue library")

- Volt: https://volt-app.com

IRC bridges (allow using Slack from native IRC clients):

- wee-slack: https://github.com/wee-slack/wee-slack

- irc-slack: https://github.com/insomniacslk/irc-slack

- bitlbee: http://bitlbee.org (using libpurple)

libpurple plugin (allows using Slack from Pidgin, Adium, bitlbee):

- https://github.com/dylex/slack-libpurple

- Adium (native macOS app) plugin based on it: https://github.com/victori/slack4adium

CLI clients:

- https://github.com/erroneousboat/slack-term

- https://github.com/haskellcamargo/sclack

- the emacs one you mentioned

Most of these clients don't support 100% of Slack's features, aren't as pretty, and are generally not as 'polished' as the official client. But they're also mostly written by individuals in their spare time, as opposed to a team of full-time employees. So no, I don't think that native clients are 'actually a lot harder to build and maintain'.

Post reply on HN