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.
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'.
To be fair, if you want it to be that pretty you will have to either reinvent two-thirds of a browser or half a game engine. There's a reason "rich UI"s are a pain to build compared to native GUIs (MSFT Xaml is more similar to a web browser than traditional winforms-style UI).
The best compromise right now is to aggressively build pretty, heavily themed prebaked designs. Think Material Design, Cupertino etc. so native UI is somewhat good looking too even though it may not be as "rich" as a React one with all the drag and drop animation and flashy trinkets. Feature wise of course there's only marginal improvement to old school Java Swing, but it's certainly easier on the eyes.
Maybe on some platforms. I'm a Mac user, so speaking for that platform, AppKit has had built-in animation support for over a decade (and now with Catalyst you can also use UIKit if you want). Drag-and-drop in particular has animations out of the box when using certain built-in widgets – e.g. when you're dragging an item into an NSOutlineView, the existing item at the cursor will slide down to make room for it. (But what in Slack is even draggable? I can't seem to drag to rearrange channels, for instance.)
Exactly my point, OS X has tons of prebuilt designs with knobs for customization. But at the end of the day they can still be built rather quickly. Drag and drop the components in Xcode, tweak a few variables and animations here and there and you have a perfect looking app that is coherent and consistent with the rest of the system. On the other hand, a modern successful SaaS requires hundreds of man hours of work just on design and UI alone. For web, nobody wants consistency. People gets upset if every site looks exactly like bootstrap. Sites have to be styled, branded, made unique. Yet for traditional desktop i.e. not electron, the moment a cross platform native UI library look vaguely off, devs throw a fit. Think Gtk, Qt, Swing etc.
Nice -- I assumed there were at least one or two, didn't know there were so many!
Once Riot and Matrix pick up steam, I suspect the Electron debate will be even less of a real issue, since you can pretty safely build a native client for Matrix and know for sure that nobody on the corporate side is going to get annoyed and tell you stop.
5. how can I make $$$ from spending a few months writing a native client? Slack can cut me off anytime they get annoyed with me. So even if my client is better, they can decide i am a threat and cut me off.
Never build your future on someone else's platform.
I completely agree, but this would fall under point 1 for me.
See Twitter for a good example of where business interests and API stability intersect in negative ways. I would make the point that if you don't trust a business to keep their official API stable, you probably shouldn't be building a community around their tools in the first place, regardless of whether or not they have a native app.
It's absolutely \#1. I tried switching to Riot (Matrix), but the integration with Slack was painful. You can get it to work well, but what's to stop Slack from breaking/changing their API periodically to make your app stop working as reliably?
If I'm going to put my resources into building a client for something, it's not going to be based on some closed source backed that could change at any time, it's going to be based on something open and forkable (worst case scenario, I can just maintain my own backend).
Slack bills itself as a complete solution, not a piece to a larger puzzle, so third party clients and plugins will always take the backseat. Who is going to try to build a serious competitor when they can't really rely on the backend staying consistent?
Building a decent frontend isn't particularly difficult. It's not trivial, but it has been done. For example, Pidgin, while a little ugly (I prefer "functional"), works well and has been around for years. I used weechat and irssi for IRC chat before we switched away from IRC, and it worked really well (didn't see pictures, but I think that's more a feature than anything, and links were more than sufficient).
The problem is that business types prefer hosted, "batteries included" solutions, and those types tend to not be very friendly with third party add-ons. If I end up being able to use Matrix/Riot, maybe I'll try my hand at a native, cross platform client. But until then, I'm not going to throw my effort toward something that can change at any moment.
I use weeslack and matterbridge.
Weeslack is a python plugin for the irc client weechat.
Matterbridge syncs slack channels with other services like telegram and irc.
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.