Shrugs.app – A native Slack client for macOS | Hacker News Reader

Shrugs.app – A native Slack client for macOS

shrugs.app

300 pointsjer0me226 comments

The first thing I looked for was a comparison with the official Slack client in terms of performance, since that's the only reason why I'd consider using this. Numbers for CPU load, memory use, time to perform certain actions, crashes. Doesn't seem to be anything available on the site regarding this, which is a shame.

Want to double-down on this. I read "native" and immediately assumed the main selling point was perf - which enticed me to open the link.

Well the other selling point would be a native UI experience. I like apps that use the native UI style of the host operating system.

Paying for native macOS apps is like buying vinyl records. It’s an aesthetic choice, nothing more.

It is a user experience choice. Most decent native macOS apps adhere to system conventions. Text editing works as one would expect in a system text field. Keyboard shortcuts behave as expected. Custom keyboard shortcut definitions from the Keyboard section in Preferences actually work. And on and on.

Slack in particular is extremely, extremely slow, even by Electron standards. I can't expand it to the full-height of a 4K (running at 1080p) portrait monitor without typing becoming unbearably laggy, so I either have to keep it at 1/3 monitor height, or have to use another application for writing the text.

it also has multiple accessibility issues for low vision users. I'd happily switch to a native client because using native widgets instead of HTML would likely address most, if not all, of my accessibility needs.

Sadly, this take misses so much about Mac native software, things that many people just do not know are possible.

- accessibility built in which benefits everyone

- native application scripting

- consistent keyboard shortcuts, including focus ring movement

- ability to App Nap / fast system shutdown

- consistent retina/DPI behavior across display drags

I've been developing Mac native software for 20 years now and I'm still wowed by some of the things that come with the toolkit for free.

An even better reason would potentially be security. Exploits in electron are pretty common, which may be a result of its ubiquity making it a big target. But also it's just a complicated platform to secure.

If I was worried about security then I think I'd probably move to using the web client (or a web wrapper) instead of switching to a third party native application.

That's a common refrain I hear that Electron apps aren't secure. It was more true in the past and less-so now. I've been maintaining a secure Electron template for 2 years that's got traction in the community, if you are interested - https://github.com/reZach/secure-electron-template.

How is installing rando native apps any more secure?

>Slack is one of the most secure Electron apps currently in existence at the moment, they have been...

And from your other comment

>we in the Slack Desktop team

Seems misleading to declare something like this without a disclaimer that you work for the company in question, especially when phrasing it as if you are definitively not a part of said company.

> crashes

I've literally never had or heard of Slack crashing, across Windows, Ubuntu and macOS, regardless of memory available (8-32GB) and use. Do people really have Slack regularly crash on them or is that just something that gets attached to Electron (for some reason).

A slack crash would be the window going white and reloading.

I get them occasionally.

An electron crash would kill the window. I get these sometimes too when I try to run natively in wayland, which I’m aware is unsupported so I’m not blaming anyone for that.

Happens to folks on my team on occasion. Slack crashing. And the whole Electron app crashing too. Linux users.

Slack crashes on my Ubuntu setup on the regular.

Grey screens. Unresponsive during video calls. Eats all of my memory at least once a day. The app is a mess.

Not a single crash on Mac in 5 months I’ve been using it. Perhaps it’s the Linux version? Or your system?

You’ve never seen Slack reload while using it? Often, that’s a “crash” in an Electron app.

I have not seen that. It's crash-free for me, running 24x7.

But all that tells you is that it's crash-free on at least a small % of machines, so not a great way to analyze robustness. Maybe create an HN poll?

> I have not seen that.

No offense, but you must have blinders on then. On a fresh install on a new machine it’ll do it in the first day.

> It's crash-free for me, running 24x7.

There was a person who legit got struck by lightning multiple times in their life and lived, so anything is possible. Your claim is comparatively improbable though, but still has the possibility of being true.

I get them all the time on my M1 Mac (Like at least once a week.) Sometimes even the white window that requires a force quit and doesn't auto-reload.

Slack crashes quite often for me-try to do too much? That’s a crash.

Accidentally toggled the “huddle” button a couple of times - it’ll crash so badly, I legitimately have to restart the computer to fix it.

I have experienced few crash like scenario with network issues on my Mac. If my wifi is poor for a minute, slack will permanently stop working unless I force reload using menu or restart it. Messaging apps are basically meant to not have permanent connection, but I have seen very few that could work with this assumption.

Slack crashes (unresponsive white window -> hard reload) for me at least once a day on the latest MacOS and Intel MBP, and it seems a common occurrence for many of the coworkers I talk to.

Slack regularly crashes with an empty window on my Mac. Not like a process crash, but the whole window going empty, needing to quit the process and reopen.

I’ve never seen one on Mac OS Slack

Most of the point of skipping electron is memory usage, which is a major issue with having a full separate installation of Chrome just to handle a webpage, which is what Slack is.

It looks nice, but if you plan to try it as you default Slack client be aware it is lacking many features:

- Edit posted messages (big one, TBA) - Authentication w/ XOXC tokens - Loading older messages - Typing indicators - Starring & Pinning things - Search - Sharing messages - Screensharing and Calls (aka Screenhero) - Joining and creating channels

Oof, I feel like just one of those would be a deal breaker for most, but all those missing together makes it feel more like a proof of concept than anything else.

A $20 proof of concept.

Gotta start somewhere.

The problem is that according to the FAQ it's more in maintenance mode than in active development.

Yeah, but multiple windows! OMG!

I find managing multiple conversations with Slack so incredibly challenging. Having multiple windows open for active conversations is sooo good.

That's interesting. I find managing Teams' multiple windows cumbersome and confusing, but find Slack very natural and efficient.

Do you end up sending messages in the wrong chat often? Or missing messages or both? What do the main frustrations of a single window setup look like?

I lose stuff all the time when I switch between conversations and channels.

try the back button to jump back to where you were before

I just navigate Slack entirely by search and redirect all conversations to public channel as as much as possible, and I find that pretty natural. CTRL+K to navigate between convos and channels, CTRL+F to find things based on content (if I don't want to think about whether something was in a DM or a channel, and just go back to the same one).

> Do you end up sending messages in the wrong chat often?

Yup. It’s probably my most frequent mistake (and can be embarrassing). I make the same mistake with messages.

What I have done to mitigate the issue, is give each workspace a different color theme. At least, it helps me to avoid crosstalk between organizations.

I’m not a “native slacker,” so I’m probably not a particularly good candidate for a focus group.

> What I have done to mitigate the issue, is give each workspace a different color theme. At least, it helps me to avoid crosstalk between organizations.

Ok yeah the different workspaces in one window is more of a pain than just different channels and chats in one window for me, at least the way it's done in Slack. I haven't felt that way on IRC, for whatever reason.

On a Mac, Teams doesn't obey many of the user interface guidelines, so multi-window use is unintuitive and difficult.

Of course nothing in Mac Teams is nearly as bad as their incoming call notification - calls pop up under all your existing calendar/email/... notifications, which you have to furiously click away in order to answer the call.

That sounds ridiculously frustrating. Does Cmd + ` pull up the call? I'm guessing no since Teams go out of its way to make notifications un-native and clunky, but maybe worth a shot.

+1 It's painful to keep multiple active discussions in threads (or anywhere else for that matter).

+1, I basically go back to the DMs page all the time to find recent convos, that's the only way I found.

I'd love to have multiple windows. At some point in the last few months Slack broke the command-up/command-down shortcuts that would take you to the next conversation with an unread message -- if you restart it'll work for a short while and then break again. Having multiple windows would resolve this and other annoyances.

It's funny to see how basically all the official mainstream IM clients like AIM, MSN, ICQ, etc. used to be 1-window-per-conversation, but then in some odd wave of "modernity" (for lack of a better term) that was all dispensed with, and then now, multiple windows is somehow heralded as a new feature again.

To me, it's just common sense that each conversation should be in its own window, instead of stuffing them all into one window that only shows one at a time.

There's another comment here about how Teams' multiple windows is confusing, but I think that's more to do with it being Teams than anything else; as I mentioned above, all IM clients were originally multiple-window and people certainly didn't have trouble using them.

Oh, this brings back lots of fun memories comparing developing SDI apps and MDI apps in Windows.

I remember when a lot of software had heaps of windows. Like graphics editing apps, logic, Final Cut etc. Been a huge cutting back on windows for apps.

Clients like Adium (on Mac OS) and Pidgin (elsewhere, but honestly nothing is as nice as Adium), had a great solution for this. A window with tabs, but you can just drag tabs out and have more than one window. Plus you could style messages client-side. Nice and easy, better than anything popular today.

Adium was everything an IM client should be. I wish it would return to relevance, but with the dominance of closed messaging protocols that seems unlikely at best.

We create the poison then drink it.

It’s more to do with having a unified experience with mobile - slack pretty much has the exact same UI on all devices (only change is whether the side bar is visible, which just depends on screen size). For better or worse, not judging here.

Slack is more like IRC and as I recall most IRC clients had single windows.

If you use a browser as your client, this can be done. No need for electron either :)

On Macos Chrome you can still do hamburger menu -> More Tools -> Create Shortcut... and enable "open as window", and Chrome will create a .app file that, when you run it, opens that site as a PWA. Additionally it gets the favicon of the site by default as its app icon (you can change that) and then it shows up in the cmd-tab list as an app completely separate from Chrome. This works really nicely with Slack, especially if you're usually only in a few slack teams. Inside the PWA Chrome apps you can do cmd-N to create a new window if you want to see multiple channels / threads side-by-side from the same slack team. It's a great user experience and pretty much the only reason I keep Chrome around.

Firefox devs removed its PWA / "site-specific browser" support in https://bugzilla.mozilla.org/show_bug.cgi?id=1682593 .

There's a GitHub project that enables you to run PWA's with Firefox as distinct apps (with thier own icons etc): https://github.com/filips123/PWAsForFirefox.

Disclaimer: Haven't tried it out myself.

Thanks, that's interesting but I'm not so anti-Chrome that I'm going to use a "custom modified Firefox runtime" just for PWAs. I don't even use the above trick these days; I've gone back to just using Slack.app.

I frequently just use slack in the browser because it has tabs and windows. And generally performs much better.

Multiple windows <3

I look at the screenshots and think "we're living in the ~future~ 1996"!

I haven’t tried this but… if you use Slack in a browser can you open new tabs for conversations?

I would also expect the authors are going to have a hard time keeping up with Slack. One of Slack's goals in picking their architecture was to allow for experimentation, iteration, and expansion. Reverse-engineering an API inevitably means being behind. And given the number of engineers Slack has, it could well mean being further and further behind over time.

When you're building on someones platform, you take a risk. When you're actively integrating with a fast moving platform, you add more risk. When you build on a platform which doesn't want you there, you add even more.

When you're having to reverse engineer a platform to build something, you're asking for a special kind of hell.

Oof, while I highly value multiple windows - not sure I am ready to give up on some of the things you listed (especially edit & calls)

missing search is a non starter. "Searchable Log of All Conversation and Knowledge" rings true in my experience

Very important line from the FAQ:

Q: Is this still developed?

Yes, it is used and developed. Just not very actively. Most importantly Shrugs does not yet support “XOXC” tokens, which are often required by company Slack installations. We are interested in adding this feature, but there is no timeline yet.

In the year or so I used it, it was never updated.

IMHO, XOXC tokens are a critical feature. If I still need the regular Slack client for work chat, now I have two Slack clients. :-(

localslackirc supports them, but it's a gateway to an IRC client, not a full client by itself.

Ripcord survived C&D letters because it didn't charge. I feel bad for OP for putting all this work in, because it's really cool - but you're going to get sued.

it sucks that you could be sued if you are using a "public" api like this to write a client.

I would like to think that as long as you do not brand yourself as slack or violate any trademarks, you should be able to write an app like this. Things like email clients would fall into this category.

It's not public as in an utility. It has its own Terms of Service.

The point is it's not fair that Terms of Service can impose that restriction. Just like it wasn't fair when you were only allowed to use phones that you rented from your phone company.

Why isn't it fair? They run the service. What gives other people the right to tell them how to run it? If you don't like their terms, there are about 100 alternative projects you can use.

There are pretty clear, practical reasons you might want to control the client of a commercial network service.

What part of your argument wasn't true of the phone company too?

The phone company is the sole-source provider and you couldn't opt for another platform. The more relevant analogy is soda fountains in a restaurant - the provider chose Coke, but I want Pepsi. (My OSS founder wanted Slack, I want discord.)

If Slack isn't the sole-source provider, then neither was the phone company, since you could also communicate by sending letters.

That's a different medium, although I understand your point: Slack is the sole source provider of communicating on the Slack network. Personally, I don't think this is a problem or should be fixed because of how I see the tradeoffs and side effects. Similarly, I want Apple to run their own app store and not allow sideloading because I prefer the set of tradeoffs that come with that, versus the other reality.

Phone companies are different in that they were monopolies with special legal status. Slack, on the other hand, is just one of many private companies offering roughly equivalent services.

You can still argue your case, of course, but phone companies are a bad analogy here.

There are reasons, but it's also not smart. Organizations that pay for Slack pay for the service, not the shitty client.

You want to reduce Slack Inc to an API provider. They want to be a client provider too and they own the API server. Do you see where this won't work?

The value of Slack Inc is their API, which is currently de-facto locked to their client. People would still pay for Slack if they could use alternative clients, because the client is not the value.

You can argue that their client is not as good as it could be, that you have greater skills to deliver a better product, etc. But it has value, otherwise we'd all be using curl to access the Slack API with no downsides. That's clearly not the case by far.

> But it has value, otherwise we'd all be using curl to access the Slack API with no downsides. That's clearly not the case by far.

Only because it's next-to-impossible to call the API, because of the way they lock features to their client!

Author of Ripcord. You’re wrong, and creating and using software compatible with services is fair.

i do agree it's fair, but it's also true that the service provider could argue that they are supposed to be in total control of the service, including the front-end.

It's by societal consensus that this can be made fair, and to convince people that it is fair, there needs to be a logical, indisputable argument that it's fair. Otherwise, the service providers can always just hide behind the counter-argument of being in control and TOS etc.

In the case of Discord, for example, the terms of service doesn't even mention third-party clients. Also, these services are accessible from web browsers, which are made by third parties. There are more reasons, like users being able to run whatever they want on their own computers, but just the ones above are enough.

"You may not copy, modify, create derivative works based upon, distribute, sell, lease, or sublicense any of our software or services"

This seems to make it pretty clear they don't want you to create 3rd-party clients for their service.

Ripcord isn't a derivative work, both practically and in the legal sense. It's implemented from scratch. Ripcord isn't a resell of their service or a sublicense of their service.

If I rephrase it like this, does it make it clear?

"You may not create derivative works based upon any of our services"

In the imaginary world where that's what the terms of service says, that's still fine for Ripcord -- Ripcord isn't a derivative work.

If the terms of service allow it, then it doesn't matter what it's fair or not: you're allowed to make a client for it. The discussion is moot.

I don't agree that fairness requires service providers to provide open APIs. Open APIs are better, ceteris paribus, but that's as far as it goes.

I assume your argument is that Slack has the "freedom of contract", the right to create and offer you contracts of their choosing (and you are free to accept or decline them). That right is not absolute. Workers rights limit it, sanctions limit it, cartel and competition laws limit it. There is no reason society can't agree to limit the options of keeping an API locked down in such contracts, especially for well established companies like Slack.

And I think the advantages of such a law are very clear: More competition on front-ends could very likely create much better user experience (better organization of chats, better message and image editor, better notifications, show users whether messages have actually been sent).

Laws are made to serve the public [1]. Being nice to companies is a means to an end, not the goal itself, and the discussion about whether API should be legally accessible to third party vendors (or devices/cars/… should be legally repairable by third party repair shops) should focus on whether we get better user experience, service, and so on, and have the question of whether companies will still want to offer backend-service like Slack under such a law as a facet.

[1] At least they should be and everybody complaints when they aren't.

Sued for what, exactly?

Violating the API Terms of Service [1]?

> [...] Further, you will not: [...] (C) access our APIs or documentation in order to replicate or compete with the Services;

[1] https://slack.com/intl/en-au/terms-of-service/api

I’m not a lawyer, but I believe Slack would have to show they were harmed in some way to successfully sue.

They can certainly attempt to block 3rd party clients, though. Or threaten to / actually sue, even if they’re unlikely to be successful.

Unlikely to be successful? This app has near zero chance of surviving a legal challenge from Slack.

Author of Ripcord. You don’t know what you’re talking about and shouldn’t broadcast your assumptions as fact.

You keep commenting one-line sentences without any argument supporting your sentence. You may even be right, but am I supposed to blindly trust you, a random commenter from the internet?

I mean, you don't have to. I appreciate the skepticism. I am the actual author of Ripcord. I've had an account here for many years. You will not find someone with better firsthand knowledge about Ripcord surviving or not surviving legal challenges.

I'd be interested to hear more about what sort of challenges you have faced, and if/how you responded to them, if you have the time.

Regardless of the upthread "well, just switch [your company/government/entire friend network] to an open/permissive service" non-answer, I think there's going to be ever-more need for unofficial clients for some of these services, and a big part of that is going to be how to avoid having them shut down immediately by service providers...

I would like to say stuff about it, but can't just yet.

Oh, you have a law license too?

They are based in Germany. They would need to be sued in Germany. Germany has legal insurance where you can get insurance and it will cover your legal bills and liabilites. On top of that Germany has legal restrictions on how much a case can cost. Slack/Saleforce would not have much benefit in a legal challenge due to their size and legal costs. Furthermore, Slack would have to have a legal case. Which they most likely won't have.

Sincere question: is an alternate app competing with Slack’s services? We pay for each user who uses Slack, whether it’s by phone, desktop, or web. The client is 100% free; the right to connect to their service is what costs money. Slack makes exactly the same whether I use their app or an alternative.

I’m definitely not a lawyer, but it’s not clear to me that this would violate the ToS.

Can they actually sue, or can they just terminate the service for this one account?

I would be confused as to how an add-on service such as a premium Slack client would compete with Slack. It seems it would be complementing it and the use of the client would not compete but fundamentally cooperate with Slack as a service.

I'm of the opinion that using unofficial clients for any online service should be a legal right (unless those unofficial clients cause harm to the respective service, but existing laws/regulations around that would already cover such cases). That doesn't mean the service has to specifically support the unofficial client, but they just can't intentionally block it (or forbid its use).

I am pretty certain that I can prove any client as harmful. I have been on the receiving end of apps misbehaving plenty of times, no matter which platform (JS, iOS, Android). And these were official apps with dedicated development teams.

Endless loops which flood you with API calls are a common issue, managing state is hard. Rate-limiting does not completely solve this.

Plus you can land in a situation where a user might associate bad experiences with an unofficial client with the actual service and thus leave with a bad impression overall.

I dont imagine that most users start with the unofficial client.

Yeah, I was thinking as I wrote it, "official clients can probably fulfill that bullet point" hahaha

Doesn't your API have a problem if it can be misused that way? In other words, shouldn't your backend by default distrust the client using its API, no matter whether it's the official one or anything else? Even the official client can have bugs that bring down your backend.

That's what the "zero trust" philosophy is about.

This is the same argument AT&T used to forbid third party telephones on their network. It didn’t convince then, and it does not convince now. Tolerating third party clients should just be part of the cost of doing business and part of the design of robust protocols.

couldn't this be addressed to some reasonable agree by requiring someone to register their client and providing a fee schedule for "misbehavior"

eg. if you send more than X requests per day per user you need to pay us $y per 100,000 requests over the limit (or whatever).

the only requirement would be registering and providing billing info, which wouldn't be used if they behaved.

hopefully people at Slack are smart and they hire the dude

but since they spit buggy electron shit for decade already, i think you are right, they'll do everything possible to shut this down and keep with their inefficient and bloated electron way

Slack is no longer a small private company. They are owned by Salesforce

IMO lawsuits are less of a concern than your end users getting banned, especially since slack is typically used for work. If your existing customers are loudly angry about you in public it's gonna make it hard to get new ones

If I got banned, I don't know what I'd do first -- open a bottle of champagne or dance a little jig?

To be fair, I'd love to see a case like this brought to court. I'm not sure there's great precedent here. I think a case could be made that Slack was not harmed through this work.

I'd like to hear a lawyer (HN has several) corroborate this "Slack must articulate harm" claim, because there is a whole branch of civil law that exists to enforce contracts in the absence of torts; as I understand it, it's called "contract law".

This is true, and not all contracts are valid. It's why I'd love to see a good case brought. I feel like every time this happens the little guy just folds instead of doubling down.

But agree, would love to see some lawyers weigh in.

The closest precedent might be something like https://en.wikipedia.org/wiki/Lexmark_International,_Inc._v..... or whatever laws make the aftermarket parts industry legal.

It does, though. You need to buy a $20 license to use Slack's features.

This is just wrong lol. Cancel has never received C&D orders for Ripcord, and it does charge $20 for the Slack features. Please don't spread misinformation you're not even informed correctly on, dude. If they were going to order a C&D order to Cancel, then they would've done it around the project's start (around 6ish years ago). Actually research this stuff before posting posts like these, plz.

From this user's top post on HN:

> Over the years I've found writing on HackerNews, Reddit and other online sites has given me an outlet to get creative and engage with folks in a way that will shift discourse towards something I'm more interested in. I regularly lie and pretend I know about topics and areas I have zero experience in. I began noticing I received more upvotes and engagement

..yikes.

someone admitting to that behavior on HN should be banned. that's actively hostile to the discourse here.

How do you see top posts?

Click on the username => submissions

Ah, ok, I would call that a “submission” but it’s an “Ask HN” so I see where you came up with “post”.

Note that the submission page is sorted chronologically, not by karma. So the concept of “top” is really more like “first”.

It seems you meant to point out that @Mandatum admitted to lying but the way you phrased it really made it difficult to verify the claim and came across to me like you were accusing @jessefied123.

There were some very strong responses [1] to your accusation and I’m concerned that anger may be directed at the wrong person. When making these kinds of accusations you should try to be more clear. Use names and provide links. Also consider if the benefit of the accusation is worth the risk of misunderstanding.

[1]: https://news.ycombinator.com/item?id=31928612

My apologies, I should've made it clear and added a link.

And indeed, the submissions are sorted chronologically. So I should've used "latest", not "top".

Should clarify: the comment above me by @amedvednikov is referring to this comment chain's original poster -- @Mandatum -- not the parent or link submitter, and the post mentioned is: https://news.ycombinator.com/item?id=30838788

Big yikes. Thanks for clearing this up. I totally misinterpreted the accusation.

My apologies, I should've made it clear and added a link.

I wouldn't be so sure. IRCCloud offers Slack connectivity (using Slack's API, not the IRC bridge that was closed long ago) and it costs money. I've used it for a couple of years now.

I was trying to remember the name of ripcord while reading this. Thanks. I used it for a while for both slack and discord and it wasn’t bad. However they did sell licenses. I just don’t think they required them. I just double checked and I bought a $20 license for it. Good software and definitely worth it as far as I was concerned.

Maybe I'm just jaded but as someone that used to be gungho about alternative, native clients like these. I've just given in and used the official clients. I'm tired of being the person who doesn't have specific feature or w/e.

Anyone else in a similar boat?

Yeah, same boat here!

Yeah, same here!

I just really want the offical clients to become native. I understand why they're not native but it really sucks.

See also: Ripcord[1], which has both Slack and Discord support.

[1]: https://cancel.fm/ripcord/

+1 for ripcord. So much better than using a bloated web browser

Won't using a 3rd party app for Discord get your account banned?

It's probably against their terms of service, so maybe. It probably depends on a combination of (over)zealous automation and whether they feel it's in their expedient interest to crack down on.

Their client exists almost entirely to collect data about you (chiefly what games you're playing and with whom.) That's one reason they are so quick to ban non-official-client users.

It's actually not https://discord.com/terms

Although like with all things, proceed with caution.

From today's conversation about Thunderbird 102: yes, it seems running a 3rd-party client has a high chance of receiving a ban.

https://news.ycombinator.com/item?id=31914288#31915716

Not necessarily, although this gets routinely brought up in the Ripcord Discord server. Ripcord essentially just uses the browser APIs, so it's not really different from opening Discord in Firefox.

That being said, Discord can ban people at random for whatever reason they choose, and this has happened before.

For the record, I've been using Ripcord with the same Discord account for 3 years, daily.

Ripcord is great and I use it for Discord and Slack, but it is far from feature complete. Important to note that Ripcord is developed by one person. Some major things that are lacking:

* No search (Slack/Discord)

* No huddles in Slack

* Thread support in Discord

For these reasons, I typically navigate to Discord/Slack in the browser when I need access to those features. Not ideal, but the snappiness of Ripcord over the slow bloat of Slack/Discord make it worth it to me.

Ripcord has had search support in Slack for a while, it's under the Workspace menu. Otherwise, yeah. It's unfortunate to have to open the browser to do some of this stuff but the day-to-day experience of using it is great.

Thanks -- I really had no idea.

I feel like it being based on Electron is the least bad thing about it. Native or not, you have to reach the API for everything and that's slow.

Agree to disagree. Selecting a channel in Slack takes like 300ms for me almost every time. There seems to be an inherent UI lag with Slack and Discord. Ripcord, on the other hand, is instantaneous.

Wholeheartedly agree that that's not acceptable performance, but blaming electron, which runs on chromium which is famously fast (despite its other issues) seems misguided.

To me it sounds like an artifact of architectural choices, eg by polling before rendering to avoid flicker, lack of client side caching, or possibly just bloat. Companies won't stop their poor software practices even if they switched to native.

It could be an artifact of architectural choices, but Microsoft Teams also has that flickering/loading when switching tabs or chats.

The post I responded to mentioned the Electron; I was talking about the client performance in the browser, but I've had similar experiences with the Electron clients for Discord and Slack.

I don't doubt you can make a performant snappy chat GUI with Electron/web tech, but more often than not, in my experience, Qt apps (like Ripcord) perform much better and are less RAM hungry.

Is there a better frontend for Ripcord? I tried it, and while it's fast, it's just so utilitarian.

Nope. The look is part of the appeal; it puts function over form, and looks native-ish instead of like a webapp.

There is a theming system included, however, it only allows you to change colors/fonts of UI elements.

I still use Ripcord at work every day, and it's fantastic.

I actually downloaded Ripcord, immediately saw that they will "never" support video calls or embed videos, and then immediately uninstalled it.

Why do a lot of these alternate clients purposefully leave out vital features?

> they will "never" support video calls

Video calls are somewhat involved, and no third-party implementation exists to my knowledge. Discord uses WebRTC over the browser, but the desktop app uses a native module written in C++ that I assume handles decoding, audio screensharing, and other related functionalities. It's not impossible of course, but the cognitive barrier is much higher than simply observing the WebSocket and HTTP requests to get text chat working.

I use Ripcord to access Slack daily and it’s… very mediocre. It uses Qt, so it looks terrible (but at least it’s not a web browser). It’s more native than an electron app, but not by a lot. It doesn’t even use native scroll bars which can be really irritating at times. All images are thumbnail size and if you click to enlarge, it dumps you to the web, which slack.com just ignores. It logs you in and then doesn’t take you to the image or file you clicked on.

I don’t hate it (as much as I hate using Slack in a web browser or electron app), but I certainly don’t love it. I’ll be giving Shrugs a try, but it sounds like it’s missing a lot, too, so I’m not hopeful.

No way I would use this for internal company stuff. Is it safe? Probably. But it's not worth the risk to me personally unless the IT/management people agree to it first. At the company I work for (and I suspect many others) Slack is a treasure trove.

my first thought - I was surprised, that I had to scroll down this far to find this post...

> We do not offer refunds. Please make sure that you can login into your Slacks and that the app works for you by using the free test version.

From my experience when someone says they don't offer refunds it's generally a sign that lots of people ask for their money back. I've not once dealt with a company that had a no refunds policy that was a good company to deal with.

It has a free version you can use. I am not sure if refunds for software purchases is the norm. Does Microsoft offers Windows or office purchase refunds?

It has a free version that is limited to the #general room which would mean for my random communities I wouldn't be able to test this out on the generic happenings. Nevermind a full blown work slack.

> I am not sure if refunds for software purchases is the norm. Does Microsoft offers Windows or office purchase refunds?

It is indeed the norm in the indie hacker world which this developer and product is part of. I don't think I've saw a software product that didn't come with a X-days money back promise.

And yes, you can get a refund for Windows. You can go here https://answers.microsoft.com/en-us/windows/forum/all/return... and see a Microsoft employee explain how to get one.

The demo version now actually supports multiple rooms (I think the 4 or 5 last you clicked). The bigger issue usually is the lack of XOXC support (as the general API gateway lacks a lot of API features).

BTW: You can also get a refund. This is more to make sure that people actually try the thing before blindly buying something. Shrugs _does_ have limitations, so it's important to first test whether it fits the needs.

I run a very small audio plugin company as a side-hustle/just for the love of it. Refunds through my payment platform cost me money. I offer a very generous trial (3 weeks unrestricted, nag screens after that). I think because of that no-one actually asks for refunds (or perhaps my plugins are good enough that everyone who buys is satisfied). I do offer refunds for accidental double purchases though (usually I'm the one who notices and pro-actively contacts the customer).

I understand that refunds cost money. I have a SaaS boilerplate (https://getparthenon.com) with a 30-day free trial and then still offer a 6-month refund policy (6-months if you pay for the year, the full currente month if you're paying monthly). Why? Because I believe in my product. I also don't want people to go around regretting buying it, if they try to make something it doesn't go well for them then they can have their money back. Also, not many people actually ask for refunds. So mostly, it's just a good policy to have that costs me very little.

> Also, not many people actually ask for refunds. So mostly, it's just a good policy to have that costs me very little.

Actually this is a very good point and I think I very well may reconsider my position, because since no-one actually ever asks for a refund perhaps it would "look" better if I didn't explicitly insist that there are "no refunds".

It’s an interesting start, but it’s missing some pretty vital features the official Slack client has.

I get how development works and I understand needing funding to support development, but I’ll be holding off on this until there is at least a much closer feature parity.

I suppose I’m getting too old to beta test daily driver software.

It’d be cool if there was a kind of “feature escrow”. You might pay $20 today, but $5 of that is held and paid to the developer once a specific feature you want is implemented.

There’s probably too much overhead to be useful, but it’d be an interesting way of prioritizing features.

I remember people on HN complaining about responsiveness. Never found it to be a problem personally.

For a very long time (ive not checked recently) slack used more memory that my IDE on a multimillion line c++ project. I used to have to shut down slack to compile on a machine with 128GB ram.

I think it improved quite a lot. I’ve just checked and it’s using 58mb on my Windows 11 workstation.

It definitely has improved. It was clear from the memory usage vs community size that they were doing something that scaled with community size. This is a guess, but something like loading every single user and their profile icon into memory.

> I think it improved quite a lot.

Maybe on Windows. My work machine (running Big Sur) currently shows:

Slack: 251.6MB

Slack Helper: 10.2MB

Slack Helper: 48.3MB (Yes, there are two of them)

Slack Helper (GPU): 316.2MB

Slack Helper (Renderer): 350.4MB

So just shy of a gig of RAM for chat.

How many gigs was it using?

At least in my case, I once caught Slack.exe on windows using 40GB of RAM. (My machine had 32GB, so you can imagine how well things were running.) The allocated space seemed to have mostly been zeroes since the Windows Kernel was able to compress a bunch of the pages to avoid running out, but it was putting so much strain on things that audio playback was dropping out.

I've changed jobs since so I don't have access to the tickets but I remember it being close to 20GB.

Well, it's a problem for me, though definitely less than it was, so I'm personally very happy that this exists. "voting with our wallets" might make Slack put it on the prio board.

Right now I'm using wee_slack.py which integrates weechat with slack; though with the obvious trade-offs.

I have 300-500ms response when clicking a channel. It’s infuriating. This happens on any browser including Electron.

that and the keyboard lag is quite noticeable (even in an m1 machine)

what is going on in software where you cant even compose text in realtime...

it's an obscenity that somebody pasting one high frame rate GIF into a slack channel can cause a quad-core, tenth generation core i7 laptop CPU to peg itself at 85% usage and begin wasting battery, heating up, spinning fans, etc.

if somebody told me twenty years ago how powerful this CPU was, relative to what I was using at the time for a desktop PC, and that a chat application could pretty much max out the CPU and use multi gigs of RAM, I would have laughed...

What does that have to do with Slack? If your computer has trouble playing high frame rate video it'll be the same on every application.

It's not just high framerate stuff, it's pervasive.

Folks used to post walls of dancing bananas in phpBB and my Pentium III could handle that without breaking a sweat.

The exact same wall of dancing bananas makes any modern CPU jump to ridiculous two-digit usage relative to the task at hand.

I was also chatting over IRC from a Palm Pilot which had something on the order of 1MB of RAM, connected over RS232 to a GPRS phone, and the current experience of chat performance is basically on par with that, which boggles the mind given that I now have ten thousand times the RAM, an internet connection that can't be saturated in practice, and latency largely bound by the speed of light.

Slack's requirements are completely ludicrous in regard of what it's set to achieve.

> it'll be the same on every application.

Except, it's not. Counterexamples of chat apps with reasonable to stellar performance abound over the last two decades.

Except that I can play a 4k 60fps 100Mbps bitrate HEVC video in vlc with 1/6th of the cpu usage slack needs to display a damned gif

I think you'll notice the CPU cannot play 4K 60fps in GIF format. Maybe the problem is literally the format itself, which is terrible. It's too bad something like MPEG or some of the animated PNG / JPEG / WEBM formats never took off for meme-y animated images.

I wonder if it would help if Slack converted gifs to MP4s in the background before displaying them, or if the perf problem is in the compositing.

> it's an obscenity that somebody pasting one high frame rate GIF into a slack channel can cause a quad-core, tenth generation core i7 laptop CPU to peg itself at 85% usage and begin wasting battery, heating up, spinning fans, etc.

There’s a setting to disable animated gifs. Which also disables party parrots and other animated crap emojis.

There it is: https://slack.com/help/articles/228023907-Manage-animated-im....

I also got tired of this especially when I wasn't even looking at Slack but it was not hidden, so it kept animating gifs and emoji etc that I can't see. Hammerspoon let me just disable them whenever I was on battery power:

https://gist.github.com/philsnow/4086e07b28d8d3cd17f5bf81ff8...

After trying microsoft teams, slack feels like a thing from the future.

But try using weechat+weeslack (+ url_hint, so that you can download urls and see images with a single shortcut) as one example of how I consider a chap app should feel.

I remember pidgin being in a similar ballpark, but I haven't used it in years.

It's a shame most other modern chat clients (ripcord, and most matrix clients) do not come even remotely close.

I get the value of using native clients but the interface design would be a hurdle for me. For example, the message window has no visual hierarchy. The spacing between each message and the space between the username and message content are nearly the same with the font size being the same— just with a heavier weight. Without being able to easily visually separate each message into a block, it just looks like a bunch of lines of text when you first look at it. It's tough to see without looking for it, but the Slack client is fantastically visually parsable. It fits a whole lot of functionality in there with very little interface clutter.

One awesome UI feature of slack is that if you paste a url onto selected test it will automatically create a hyperlink. GitHub markdown does this too. Once you use, it is frustrating when clients don’t implement it. Looking at you, Jira.

Also one of the worst features if you paste hostnames that are now webpages. Always needs ``` - horrible for ops.

How long until this gets banned?

It's been around for quite some time now, so... ;P

Perhaps when it becomes popular ...

I don't think slack bans clients. They even document their API…

I maintain an IRC gateway and have never been harassed (except by users using whatever strange distribution and being unable to figure out how to run the thing… they could just get debian but noooo)

Why on earth would I want to look up flights in a slack client?

I think that is just a macOS thing, you can do that with a flight number in Messages.app today.

It's built into the OS. You can do it in any app that chooses to support it. (NSDataDetector or some such.)

It's a demonstration of OS integration.

Shrugs paying customer here - I emailed the devs about several significant bugs that were pretty much ignored. The client doesn’t support some important features, making it basically not useful as a daily driver.

It also has weird unread flagging behaviors that just drive you nuts.

Would not recommend.

From a UX perspective, it could be useful to have different windows with different recurrent/common conversations. I always interact with the same people and channels, and I find myself constantly Cmd-K to those convos. If I could have several chat windows, I'd just arrange them on my second monitor and have the top-3 laying out there, so I just rotate my head, focus on the right convo, type and submit.

Same as for reading, sometimes I just receive a quick message (like: "changes deployed"). I have to Cmd-K, losing focus of my current conversation just to switch to the other window and see that.

Just an idea tho.

EDIT: this is what I'd do: https://i.imgur.com/kI0Ti9u.png

> There is nothing about Electron that constrains it to a single window, what a weird idea.

"Native" means both using the right UI toolkit and being a good citizen by supporting features that are table stakes for apps on the platform. Slack happens to do neither. Look, I understand that UI design is hard, but there's a lot of options that are better than "let's not do it at all". Shrugs has picked one and I think it's all the better for it.

The UI would be the same except the tab would be fixed a specific conversation. Perhaps worth an experiment. I know the purist UX view would want to adapt it to then make the new tabs seamless and so on but I would expect most users just really want to have tabs per conversation or chat or thread and be able to cycle tabs instead of cycling conversations using shortcuts. You are discounting how much comfort the brain gets from a mental model you are used to, and the most common app for people to use is the web browser, which works with tabs for conceptual separation of topics, which is a great analog to different conversations or threads.

iChat, AIM, Messenger, and Adium all had the concept of multiple windows for different chats.

> If you take more than a few minutes to think out how it works (I know, not popular for the typical HN poster)

Such a condescending remark. This kind of thing is not good PR for your company, product or workplace. Would I want to work with colleagues who publicly disparage a whole community like that? If you communicate like that publicly, how can I expect your internal work atmosphere to be?

I know you're probably an engineer at Slack and not in the PR department, but you may want to re-think your communication strategy. I know that my employer would have been unhappy with me for such a comment, and rightfully so.

Judging by other comments in this thread, folks have apparently thought out how it could work for "more than a few minutes", so not just the style but even the content of your message are clearly off. You are getting community feedback here and competent people are giving suggestions -- for free. Embrace that.

> There is nothing about Electron that constrains it to a single window, what a weird idea.

Yet, for some reason, almost none of Electron apps that I'm aware of uses more than one window.

The comment has been edited as if to be deleted. Does anyone have the original?

The commenter said they worked at Slack in the Desktop app team. He quoted the app page where it says that Shrugs.app supports multiple windows because it's a native app and said that nothing prevented Electron (or the official Slack app) to have multiple windows. It was just that they decided not to do it because of UX reasons.

As much as I hate the slack electron app, I'm not completely sure I have a need for a native Mac app also if its not the official client with full feature parity. Also, I don't want more windows please.

This is a great start but two things:

1) the Github integration doesn't seem to be rendering the URLs properly which is a dealbreaker, my development channel is way less readable

2) Changing the default fonts would be a nice-to-have

I misread and thought this was a native version of a shrug copier for Slack, like https://shru.gg/

This is one of the least attracting landing page for one of the most attracting tool I've seen.

I just want a slack CLI client

it exists! https://github.com/wee-slack/wee-slack

It has been unable to log in for the last year: https://github.com/wee-slack/wee-slack/issues/844

That description's accurate, but kind of burying the fact that it's clearly being worked on and has recent commits with people testing it.

(Scroll through the issue to the bottom)

Also it was inaccurate in that it's only been broken 364 days, not a year.

An emacs slack client maybe: https://github.com/yuya373/emacs-slack?

Just use localslackirc and whatever textual irc client you want perhaps.

Awkward, but the ¯\_(ツ)_/¯ on the title isn't working.

No, I'm not paying for unfinished product!

Interesting

Reply on news.ycombinator.com