Shrugs 1.0

Just one guy can make this, meanwhile multimillion-dollar companies complain that it's just too hard to make native apps. Embarrassing.

@Alexander H

Probably not as great on the Mac, since it's built with Qt, but Ripcord is another client done by a single indie developer. Supports Windows, Linux, and Mac:

https://cancel.fm/ripcord/

So, fully agree on the whining that it's too hard to build native apps. As a bonus, Ripcord uses 33MiB RAM on my Linux machine and about 60-70MiB on my Mac.

Just one guy can make this, meanwhile multimillion-dollar companies complain that it’s just too hard to make native apps. Embarrassing.

I think with Slack in particular, one of the problems is all those mini-apps you can embed. Not sure if Shrugs handles those at all. Similarly, I can see the argument that Apple’s Messages needs to move to Catalyst; it makes it a lot easier to maintain compatibility with stuff like… uh… lasers, I guess.

But I definitely agree. When Twitter was announced as a Catalyst apps, I couldn’t help but ask myself how 4,600 employees cannot manage to make an AppKit app. Especially when they already bought one.

@Sören: Shrugs can display (in addition to the old-style "attachments') most of BlockKit's elements (https://api.slack.com/block-kit), including interactive ones. Responding to them requires a client token (unofficial API), but also works to some degree (not 100% complete implementation, but doesn't lack much, most apps I use work fine).

Note that those "mini apps" do not run as part of the client, they run on some app provided web service. The client "just" makes Slack hit the endpoints of those web services (i.e. no app provided JavaScript is run as part of the client [, yet?]).

Note that those “mini apps” do not run as part of the client, they run on some app provided web service. The client “just” makes Slack hit the endpoints of those web services (i.e. no app provided JavaScript is run as part of the client [, yet?]).

…oh? Huh. I see the point of using Electron for Slack far less, then.

For Visual Studio Code, for example, I’m not a fan of it being Electron, but I kind of get it: part of the benefit is that they got to use JavaScript as a straightforward way to write extensions.

@Sören The point in using Electron is that you can get a cross platform app with very little effort, and the official Slack app is (IMO) better than just using it in the browser - it provides at least some integration. W/o Electron, there would probably be no macOS (or Linux) app _at all_.

Slack does indeed have native clients for Android and iOS (which is also relevant to your JS app assumption). Because most of their user base is using either one of those, so that warrants the significant extra effort.
The user base for a macOS (or Linux) client is tiny, for macOS I think it is 1% _at best_ (assuming 10%(-20%?) Mac users, and (5%-)10% users who actually care about things like the HIG). This is still a fine target audience for a tinsy company like me, but it explains why this isn't a huge thing for Slack itself (well, you could argue that the most important users probably have Macs and care ;-) ).

BTW: I enjoyed this podcast episode (transcript part of the link) where the Slack CEO also talks about those things: https://www.theverge.com/21269875/slack-ceo-stewart-butterfield-interview-microsoft-remote-work-vergecast