48 ms·

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

_bxg1 7y ago
No matter the available resources, maintaining three separate desktop apps as well as a web app would mean fewer features and more bugs across the board. And Linux would probably be left on Electron (with less support attention), if not abandoned altogether.
- sagichmal 7y ago
  Past a certain point, the downsides of Electron outweigh the downsides of native apps. We've crossed that Rubicon years ago.
  - bengale 7y 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.
    - wlesieutre 7y ago
      The upsides are for the companies shipping it, the downsides are for the users. So it's not a surprising outcome.
      - _bxg1 7y ago
        Tell that to people who want to use modern services on a Linux workstation
        wlesieutre 7y ago
        That's nice for them, but no matter what OS you're on the desktop client is probably crappier than loading up the webpage, with the one upside of giving you a separate icon in the dock and app switcher. Even with the performance improved, the "stuff the whole app in one web view" implementation is still showing. Clearly this isn't an Electron limitation; VS Code handles multiple windows just as well as any other text editor. Slack's desktop client is basically "It's a web browser except worse and with the URL bar hidden." Since chat requires an internet connection and it's not like Slack's desktop version launches particularly fast, I'm not sure that it does anything better than using a browser. We'll see if they support multiple instances on iOS 13. If they do, maybe we can get a Mac version based on that for something closer to native desktop behavior.
        _bxg1 7y ago
        > no matter what OS you're on the desktop client is probably crappier than loading up the webpage I don't see how it could ever be worse than the webpage. And it gives you nice perks like notification badge integration, which for me personally is essential.
        wlesieutre 7y ago
        My web browser has windows and tabs and lets me open Slack in multiple places if I want to see more than one view of Slack at the same time. I usually don't need to do that, but when I do it's annoying that the desktop client prevents it. It's fine that my phone doesn't let me open two text conversations at once since that's all the space it has, but on a computer with a 24+ inch screen and multiple virtual desktop spaces with different sets of tasks, it's a pointless limitation.
        wlesieutre 7y ago
        For reference - the saddest little File menu https://i.imgur.com/YPoCmbR.png https://i.imgur.com/YPoCmbR.png
    - _bxg1 7y ago
      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.
      - dictum 7y ago
        32GB workstations are the exception, not the norm. I'd wager most people are using Slack from computers with 8GB RAM (e.g. every 13 inch Macbook Pro that isn't built to order) and at least one browser open at all times. (I'm not against web APIs as a platform for desktop apps, but I'm happier using Webkit wrappers and I think this would be improved, cross-platform, if Chrome could effectively host the apps that currently ship with their own instance of Electron or CEF)
      - ckuhl 7y ago
        I think it definitely depends on your use-case. Like you wrote, if everything else you have open also churns through battery life, it's unlikely having Slack open will make a difference. However, if your other applications are a terminal, other efficient text editor (e.g. Sublime), and other generally respectful apps, I've found having Slack open is the difference between having enough battery life to work all day, and not.
      - oselhn 7y ago
        But that is just one one electron app. Imagine that every desktop app you use is written in electron. I am pretty sure that even 32GB workstation would be stretched to the limits.
    - sagichmal 7y ago
      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.
  - snowwrestler 7y ago
    Pretty sure we crossed the Rubicon in the other direction, as it was basically the popularity of Electron apps that forced Microsoft to abandon their own browser rendering engine in favor of Chromium. If you had come to me 10 years ago and said "Microsoft will drop their browser and use Google's code," I absolutely would not have believed you.
    - saagarjha 7y ago
      > it was basically the popularity of Electron apps that forced Microsoft to abandon their own browser rendering engine in favor of Chromium I don't see how this has anything to do with the point here (browser engines are not normal applications…) or if it's even true.
- Eric_WVGG 7y ago
  What about React Native on the desktop?
  - _bxg1 7y ago
    React Native isn't a zero-effort way to port a web app to a native app. It lets you share code where it makes sense, but you're still maintaining separate applications targeting different platforms that each have their own quirks and needs. It's similar to how you can't just port a regular native desktop app by using a different compiler; your business logic may be compatible, but you'll still have to do legwork on top of it.
    - Eric_WVGG 7y ago
      I know, I'm a React Native developer. I'm just saying that "native client" doesn't necessarily mean separate Mac, Windows and Linux ports; furthermore, for a billion dollar company, a native client of _some_ kind isn't an unrealistic demand.
      - _bxg1 7y ago
        That's fair; although I'm pretty sure they wouldn't be able to have such a consistent and unique look-and-feel with React Native (you can correct me if I'm wrong). It's debatable whether that's a good tradeoff, but it's totally one that some people would make.
        Eric_WVGG 7y ago
        well, consistent with what? If you mean the native Mac/Windows/Linux desktop experience, yes, it's definitely impractical to do that with any size budget. But the current Electron app isn't either. But if you want consistency with the web app, I don't see anything difficult about that. I do wonder if the plugin/extensibility architecture — "Slack Apps" like Github and IMGUR and OpenTable — is the real answer. (Unless I'm mistake and these run on the native mobile apps.)
- Flow 7y ago
  I think fewer features can be a very good thing actually.
- buboard 7y ago
  You 'd think that a software company that just went public for tens of billions would be able to produce 3 programs.
dewey 7y ago
As much as I'd love a native app, for a fast moving company with rolling releases it's probably very hard to keep three platforms at the same level especially if you want to do experiments too or roll out features to a small subset.
- sagichmal 7y ago
  > for a fast moving company with rolling releases Name three major feature improvements to Slack in the last three years. I can think of one, threads, which are a fucking usability disaster and should have been killed immediately. I can't think of a single other major feature.
  - ebiester 7y ago
    It's not perfect, but we've used it extensively.
  - snypox 7y ago
    Threads are my favourite feature.
  - eeeeeeeeeeeee 7y ago
    I like threads. Especially in busy rooms, or where you need a quick diversion of a topic that only affects some of the participants in the room. I use it for incident updates internally too so the discussion is grouped. Much easier than paging through the channel.
notatoad 7y ago
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.
- ch_sm 7y ago
  not irrational. the performance problems can be measured and are noticeable in everyday use.
  - notatoad 7y ago
    how can you measure the performance difference between an app that exists and one that doesn't?
    - stephenr 7y ago
      Chat apps have been around for literally decades. There’s plenty of prior and current competing apps that do essentially the same thing and use a fraction of the resources.
      - dmitriid 7y ago
        Very few prior apps did what Slack is doing [1] And there are not that many actual competitors if you start counting them. [1] It's still strange to me that many people compare Slack to IRC and XMPP and complain that they were doing all the same things, why have people abandoned them. Even though they (and especially the clients) were doing (or capable of doing) just a small fraction of what Slack is doing.
      - notatoad 7y ago
        there's also web-based chat apps that use next-to-no resources. If slack's webapp is so heavy, what makes you think a native app from the same company would be considerably better?
throwaway66666 7y ago
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 Slack has, and stayed native and close to the metal forever. A better answer would be, that Slack has deemed the benefits that would result from this as not that important. Or that the current team's expertise cannot handle the task. But they always looking into ways of improving the core product and experience.
- bendixso 7y ago
  It is telling that the person arguing in favor of native C/C++ has to use a throwaway account for fear of going against the dominant force of opinion in our industry. We should be able to have these conversations openly without wondering if it makes us less employable.
  - hellofunk 7y ago
    You shouldn't make assumptions about why someone's account is named throwaway.
    - bendixso 7y ago
      Fair point. It's a thought that has gone through my head a few times. There are places that want you to conform to whatever it is we call "modern" software development, and I often find myself feeling uncomfortable about expressing an alternate viewpoint. There's no conspiracy or anything going on here, and you're right it's wrong to assume. That's the general sentiment of what I was trying to say though.
  - qudat 7y ago
    Please. This is literally the same argument I read over and over again on HN. This IS the bastion for this kind of argument.
guessmyname 7y ago
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/ https://cancel.fm/ripcord/ [2] https://news.ycombinator.com/item?id=19617699 https://news.ycombinator.com/item?id=19617699
- deedubaya 7y ago
  Looks neat. Definitely a developer-designed UI.
- mtarnovan 7y ago
  Thanks, I'll take a look. I tried https://volt-app.com https://volt-app.com a while ago but it had some bugs that made it unusable (for me) with Slack. I'm also a bit concerned of using a closed-source client with Slack.
  - atombender 7y ago
    The Volt app actually looks in your browser files to steal its Slack login session cookie: https://github.com/voltapp/volt/issues/143 https://github.com/voltapp/volt/issues/143.
- cat199 7y ago
  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
  - setr 7y ago
    I was also a little confused about this, because I vaguely remember slack locking down its API, and people complaining of the resulting inability for switching to a different, and possibly more efficiently implemented, UI
  - pmarreck 7y ago
danShumway 7y ago
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 maintain than typical HN posters claim. 3. For all everyone complains about Electron, maybe the current app is good enough for pretty much everyone, including the complainers, and those complaints are largely just hot air. or 4. A few good, Open Source native ports already exist, and people are just unaware of them. Regardless, the HN crowd is made up of developers who know how to develop things and use experimental software -- most people on here know how to extract a login tokin, and a lot of people on here are willing to put in a lot of effort to solve problems. If there isn't a native port already, there's very likely a good reason for that. If there isn't a good reason for it, and it's just that somehow nobody on HN has thought to sit down and build a native app yet, then I'd welcome one, I suppose. But obviously I'm not annoyed enough by Slack to do it myself, and I suspect that most other people posting here fall into that category as well.
- comex 7y ago
  > 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/ https://cancel.fm/ripcord/ - Wey: https://github.com/yue/wey https://github.com/yue/wey ("written in Node.js with native UI powered by the Yue library") - Volt: https://volt-app.com https://volt-app.com IRC bridges (allow using Slack from native IRC clients): - wee-slack: https://github.com/wee-slack/wee-slack https://github.com/wee-slack/wee-slack - irc-slack: https://github.com/insomniacslk/irc-slack https://github.com/insomniacslk/irc-slack - bitlbee: http://bitlbee.org http://bitlbee.org (using libpurple) libpurple plugin (allows using Slack from Pidgin, Adium, bitlbee): - https://github.com/dylex/slack-libpurple https://github.com/dylex/slack-libpurple - Adium (native macOS app) plugin based on it: https://github.com/victori/slack4adium https://github.com/victori/slack4adium CLI clients: - https://github.com/erroneousboat/slack-term https://github.com/erroneousboat/slack-term - https://github.com/haskellcamargo/sclack 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'.
eeeeeeeeeeeee 7y ago
Why would they do it? I want a native Slack app, but they have no incentive to do so. Look at where Slack has grown with their current app and ecosystem. I’ve never heard a single company say they’re moving to Microsoft chat because of Electron, or going back to IRC. It seems Slack has addressed the major issue with their current app with this rewrite — multiple workspaces.

No matter the available resources, maintaining three separate desktop apps as well as a web app would mean fewer features and more bugs across the board. And Linux would probably be left on Electron (with less support attention), if not abandoned altogether.

sagichmal 7y ago
Past a certain point, the downsides of Electron outweigh the downsides of native apps. We've crossed that Rubicon years ago.
- bengale 7y 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.
  - wlesieutre 7y ago
    The upsides are for the companies shipping it, the downsides are for the users. So it's not a surprising outcome.
    - _bxg1 7y ago
      Tell that to people who want to use modern services on a Linux workstation
      - wlesieutre 7y ago
        That's nice for them, but no matter what OS you're on the desktop client is probably crappier than loading up the webpage, with the one upside of giving you a separate icon in the dock and app switcher. Even with the performance improved, the "stuff the whole app in one web view" implementation is still showing. Clearly this isn't an Electron limitation; VS Code handles multiple windows just as well as any other text editor. Slack's desktop client is basically "It's a web browser except worse and with the URL bar hidden." Since chat requires an internet connection and it's not like Slack's desktop version launches particularly fast, I'm not sure that it does anything better than using a browser. We'll see if they support multiple instances on iOS 13. If they do, maybe we can get a Mac version based on that for something closer to native desktop behavior.
        _bxg1 7y ago
        > no matter what OS you're on the desktop client is probably crappier than loading up the webpage I don't see how it could ever be worse than the webpage. And it gives you nice perks like notification badge integration, which for me personally is essential.
        wlesieutre 7y ago
        My web browser has windows and tabs and lets me open Slack in multiple places if I want to see more than one view of Slack at the same time. I usually don't need to do that, but when I do it's annoying that the desktop client prevents it. It's fine that my phone doesn't let me open two text conversations at once since that's all the space it has, but on a computer with a 24+ inch screen and multiple virtual desktop spaces with different sets of tasks, it's a pointless limitation.
        wlesieutre 7y ago
        For reference - the saddest little File menu https://i.imgur.com/YPoCmbR.png https://i.imgur.com/YPoCmbR.png
  - _bxg1 7y ago
    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.
    - dictum 7y ago
      32GB workstations are the exception, not the norm. I'd wager most people are using Slack from computers with 8GB RAM (e.g. every 13 inch Macbook Pro that isn't built to order) and at least one browser open at all times. (I'm not against web APIs as a platform for desktop apps, but I'm happier using Webkit wrappers and I think this would be improved, cross-platform, if Chrome could effectively host the apps that currently ship with their own instance of Electron or CEF)
    - ckuhl 7y ago
      I think it definitely depends on your use-case. Like you wrote, if everything else you have open also churns through battery life, it's unlikely having Slack open will make a difference. However, if your other applications are a terminal, other efficient text editor (e.g. Sublime), and other generally respectful apps, I've found having Slack open is the difference between having enough battery life to work all day, and not.
    - oselhn 7y ago
      But that is just one one electron app. Imagine that every desktop app you use is written in electron. I am pretty sure that even 32GB workstation would be stretched to the limits.
  - sagichmal 7y ago
    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.
- snowwrestler 7y ago
  Pretty sure we crossed the Rubicon in the other direction, as it was basically the popularity of Electron apps that forced Microsoft to abandon their own browser rendering engine in favor of Chromium. If you had come to me 10 years ago and said "Microsoft will drop their browser and use Google's code," I absolutely would not have believed you.
  - saagarjha 7y ago
    > it was basically the popularity of Electron apps that forced Microsoft to abandon their own browser rendering engine in favor of Chromium I don't see how this has anything to do with the point here (browser engines are not normal applications…) or if it's even true.
Eric_WVGG 7y ago
What about React Native on the desktop?
- _bxg1 7y ago
  React Native isn't a zero-effort way to port a web app to a native app. It lets you share code where it makes sense, but you're still maintaining separate applications targeting different platforms that each have their own quirks and needs. It's similar to how you can't just port a regular native desktop app by using a different compiler; your business logic may be compatible, but you'll still have to do legwork on top of it.
  - Eric_WVGG 7y ago
    I know, I'm a React Native developer. I'm just saying that "native client" doesn't necessarily mean separate Mac, Windows and Linux ports; furthermore, for a billion dollar company, a native client of _some_ kind isn't an unrealistic demand.
    - _bxg1 7y ago
      That's fair; although I'm pretty sure they wouldn't be able to have such a consistent and unique look-and-feel with React Native (you can correct me if I'm wrong). It's debatable whether that's a good tradeoff, but it's totally one that some people would make.
      - Eric_WVGG 7y ago
        well, consistent with what? If you mean the native Mac/Windows/Linux desktop experience, yes, it's definitely impractical to do that with any size budget. But the current Electron app isn't either. But if you want consistency with the web app, I don't see anything difficult about that. I do wonder if the plugin/extensibility architecture — "Slack Apps" like Github and IMGUR and OpenTable — is the real answer. (Unless I'm mistake and these run on the native mobile apps.)
Flow 7y ago
I think fewer features can be a very good thing actually.
buboard 7y ago
You 'd think that a software company that just went public for tens of billions would be able to produce 3 programs.

dewey 7y ago

As much as I'd love a native app, for a fast moving company with rolling releases it's probably very hard to keep three platforms at the same level especially if you want to do experiments too or roll out features to a small subset.

sagichmal 7y ago
> for a fast moving company with rolling releases Name three major feature improvements to Slack in the last three years. I can think of one, threads, which are a fucking usability disaster and should have been killed immediately. I can't think of a single other major feature.
- ebiester 7y ago
  It's not perfect, but we've used it extensively.
- snypox 7y ago
  Threads are my favourite feature.
- eeeeeeeeeeeee 7y ago
  I like threads. Especially in busy rooms, or where you need a quick diversion of a topic that only affects some of the participants in the room. I use it for incident updates internally too so the discussion is grouped. Much easier than paging through the channel.

notatoad 7y ago

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.

ch_sm 7y ago
not irrational. the performance problems can be measured and are noticeable in everyday use.
- notatoad 7y ago
  how can you measure the performance difference between an app that exists and one that doesn't?
  - stephenr 7y ago
    Chat apps have been around for literally decades. There’s plenty of prior and current competing apps that do essentially the same thing and use a fraction of the resources.
    - dmitriid 7y ago
      Very few prior apps did what Slack is doing [1] And there are not that many actual competitors if you start counting them. [1] It's still strange to me that many people compare Slack to IRC and XMPP and complain that they were doing all the same things, why have people abandoned them. Even though they (and especially the clients) were doing (or capable of doing) just a small fraction of what Slack is doing.
    - notatoad 7y ago
      there's also web-based chat apps that use next-to-no resources. If slack's webapp is so heavy, what makes you think a native app from the same company would be considerably better?

throwaway66666 7y ago

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 Slack has, and stayed native and close to the metal forever. A better answer would be, that Slack has deemed the benefits that would result from this as not that important. Or that the current team's expertise cannot handle the task. But they always looking into ways of improving the core product and experience.

bendixso 7y ago
It is telling that the person arguing in favor of native C/C++ has to use a throwaway account for fear of going against the dominant force of opinion in our industry. We should be able to have these conversations openly without wondering if it makes us less employable.
- hellofunk 7y ago
  You shouldn't make assumptions about why someone's account is named throwaway.
  - bendixso 7y ago
    Fair point. It's a thought that has gone through my head a few times. There are places that want you to conform to whatever it is we call "modern" software development, and I often find myself feeling uncomfortable about expressing an alternate viewpoint. There's no conspiracy or anything going on here, and you're right it's wrong to assume. That's the general sentiment of what I was trying to say though.
- qudat 7y ago
  Please. This is literally the same argument I read over and over again on HN. This IS the bastion for this kind of argument.

guessmyname 7y ago

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/ https://cancel.fm/ripcord/ [2] https://news.ycombinator.com/item?id=19617699 https://news.ycombinator.com/item?id=19617699

deedubaya 7y ago
Looks neat. Definitely a developer-designed UI.
mtarnovan 7y ago
Thanks, I'll take a look. I tried https://volt-app.com https://volt-app.com a while ago but it had some bugs that made it unusable (for me) with Slack. I'm also a bit concerned of using a closed-source client with Slack.
- atombender 7y ago
  The Volt app actually looks in your browser files to steal its Slack login session cookie: https://github.com/voltapp/volt/issues/143 https://github.com/voltapp/volt/issues/143.
cat199 7y ago
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
- setr 7y ago
  I was also a little confused about this, because I vaguely remember slack locking down its API, and people complaining of the resulting inability for switching to a different, and possibly more efficiently implemented, UI
- pmarreck 7y ago

danShumway 7y ago

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 maintain than typical HN posters claim. 3. For all everyone complains about Electron, maybe the current app is good enough for pretty much everyone, including the complainers, and those complaints are largely just hot air. or 4. A few good, Open Source native ports already exist, and people are just unaware of them. Regardless, the HN crowd is made up of developers who know how to develop things and use experimental software -- most people on here know how to extract a login tokin, and a lot of people on here are willing to put in a lot of effort to solve problems. If there isn't a native port already, there's very likely a good reason for that. If there isn't a good reason for it, and it's just that somehow nobody on HN has thought to sit down and build a native app yet, then I'd welcome one, I suppose. But obviously I'm not annoyed enough by Slack to do it myself, and I suspect that most other people posting here fall into that category as well.

comex 7y ago
> 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/ https://cancel.fm/ripcord/ - Wey: https://github.com/yue/wey https://github.com/yue/wey ("written in Node.js with native UI powered by the Yue library") - Volt: https://volt-app.com https://volt-app.com IRC bridges (allow using Slack from native IRC clients): - wee-slack: https://github.com/wee-slack/wee-slack https://github.com/wee-slack/wee-slack - irc-slack: https://github.com/insomniacslk/irc-slack https://github.com/insomniacslk/irc-slack - bitlbee: http://bitlbee.org http://bitlbee.org (using libpurple) libpurple plugin (allows using Slack from Pidgin, Adium, bitlbee): - https://github.com/dylex/slack-libpurple https://github.com/dylex/slack-libpurple - Adium (native macOS app) plugin based on it: https://github.com/victori/slack4adium https://github.com/victori/slack4adium CLI clients: - https://github.com/erroneousboat/slack-term https://github.com/erroneousboat/slack-term - https://github.com/haskellcamargo/sclack 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'.

eeeeeeeeeeeee 7y ago

Why would they do it? I want a native Slack app, but they have no incentive to do so. Look at where Slack has grown with their current app and ecosystem. I’ve never heard a single company say they’re moving to Microsoft chat because of Electron, or going back to IRC. It seems Slack has addressed the major issue with their current app with this rewrite — multiple workspaces.