How about a native client? I think it's safe to assume that Slack has the resources for this.
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.
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.
https://en.wikipedia.org/wiki/Glitch_(video_game)
That core team therefore had a lot of frontend web dev experience. It made sense that they'd stick to their strengths
Can you see how maybe other people might have valid concerns about the effects of a product, and ask for more rigor in the company's processes?
That's perhaps the most tortured analogy I've ever heard. I can't even begin to fathom how you think that's comparable or relevant.
Sounds like it got my point across. You just don’t like the point.
Slack is successful because of marketing, not technical superiority.
I worked at a small company that used Google Talk for office chat, and us developers complained because it was difficult to have a group conversation with. We started using Discord (we were familiar with it and liked the dark theme) and it caught on and we were quite productive with it. Our business types saw it and decided to "formalize" it, so they picked Slack and rolled it out company wide. Most people actually preferred Discord, but the business types preferred Slack (probably mostly because of marketing), and now we're all using Slack.
Now, Slack also didn't royally screw up as it scaled up (outages were rare and transparently reported), which is a credit to the developers and PR people. That being said, just because something is successful doesn't mean it's good; it could be, but that's tangential to the topic at hand.
OpenGL is dying. It's already deprecated on MacOS.
https://appleinsider.com/articles/18/06/04/opengl-opencl-dep...
OpenGL effectively should die... but it's not going to be in favor of raw Metal/Vulkan, except in rare cases. Most people already use engines that abstract most of that away, and Metal/Vulkan are in basically every way better for those engines.
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.
Native GUI clients:
- Ripcord: https://cancel.fm/ripcord/
- Wey: https://github.com/yue/wey ("written in Node.js with native UI powered by the Yue library")
- Volt: https://volt-app.com
IRC bridges (allow using Slack from native IRC clients):
- wee-slack: https://github.com/wee-slack/wee-slack
- irc-slack: https://github.com/insomniacslk/irc-slack
- bitlbee: http://bitlbee.org (using libpurple)
libpurple plugin (allows using Slack from Pidgin, Adium, bitlbee):
- https://github.com/dylex/slack-libpurple
- Adium (native macOS app) plugin based on it: https://github.com/victori/slack4adium
CLI clients:
- https://github.com/erroneousboat/slack-term
- https://github.com/haskellcamargo/sclack
- the emacs one you mentioned
Most of these clients don't support 100% of Slack's features, aren't as pretty, and are generally not as 'polished' as the official client. But they're also mostly written by individuals in their spare time, as opposed to a team of full-time employees. So no, I don't think that native clients are 'actually a lot harder to build and maintain'.
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.
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.
Never build your future on someone else's platform.
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.
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.
It was posted a few months ago [2] and I’ve been using it since then, it works great.
I'm also a bit concerned of using a closed-source client with Slack.
"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
The only "ideological battles" are religious in nature. I'm fine with keeping religion off HN, but you can't just call a contentious topic "ideological", especially if there is evidence and/or rational debate to be had. The fact that an insufficient number of people opt-in to discussing some topic in that way does not make it "ideological". Would you also consider conversation about climate change "ideological" and thus unworthy of HN?
In any event, the original post (interestingly) got unflagged, so this was superfluous anyway.
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.
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.
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.
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.
(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)
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.
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.
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.
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.
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.
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.)
[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.
The question is whether the shared part is written in C++ vs. JavaScript.
also, whether the shared part is 98% of the code or 50% of the code.
For years slack has been a resource pig on desktop and on the web. So what improvements are you imagining they’ve been working on? Chatting on the internet is hardly such a groundbreaking subject that it can’t be done efficiently.
the ones that are described in the blog post that you're currently commenting on
Thank you for making my point for me.
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.
I use it for incident updates internally too so the discussion is grouped. Much easier than paging through the channel.
It seems Slack has addressed the major issue with their current app with this rewrite — multiple workspaces.