It still amazes me that Slack, with its infinite resources, hasn’t built native clients. One code base is nice and all, but man I loathe the Electron app.
I've thought the same thing. But also the results speak for themselves: is Slack actually struggling because they don't have native apps? What's the cost to their business bottom line? What motivations would drive it to ever be a priority?
I think this is an example of a community of nerds forgetting that we're something like 0.1% of a product's userbase.
I think the perpetual anti-electron sentiment is a strong example of how you need to be careful not to listen to just your most vocal customers. Otherwise you might triple your engineering load without even a fraction of practical, real life, measurable benefit.
I think that having just one common ui system makes a lot of sense. We want web apps to work as well as Native applications, and vise-versa.
I support the concept of Electron, but my question is - exactly why is it so bloated? Doesn’t it come with a built-in Chromium? Why is that? Wouldn’t it make more sense if it used the machine’s default browser engine? You would need to look out for different browser versions, but we are already doing that for the web anyways.
If not that... then maybe a single electron-specific chromium engine that is shared across electron apps.
What are some examples of well-written UI-heavy native desktop apps? I'm curious because I see the usual complaints whenever Slack (or another Electron app) is mentioned, and largely agree with them, but what's an app that has actually done native well across Windows/macOS/Linux?
I want to remind that Slack is not a simple chat app - it should not be oversimplified, because it has tons of added functionality. Not that you said that but it's easy to fall into that trap.
That being said, creating a native app for 2-3 (depends if you include Linux) different OS with completely different frameworks and maintaining feature parity between them involves a lot of specific knowledge and (probably) separate teams. Even if you have a good budget ("infinite resources" is quite arguable) it adds a lot of complexity to something that already has it. All of that just to somehow have a bit more fluent client (but probably much less polished).
The cost for this change would be very, very difficult to justify.
Honest question: would you buy a third party native Slack client?
I started an open source Slack client but was struggle to find tractions. Yes the Slack electron client is bad, I hate it with passion but it just works. And most of the users I surveyed think so too. Either they’re not using Slack at all, or they just don’t care if it’s electron/web-based/slow (Stockholm syndrome?).
I was trying to update my all-in-one duct tape Docker image[0] yesterday and was surprised to see that they ramped up the complexity so much for this release, I had to install a new C library just to be able to compile a dependency of a dependency they added.[1]
I've done the integration with 10+ different chat API's, Slack is one of the most complicated ones and the one that ignored the whole industry at all. The way it is done is totally alien to any experience you might have with other chat sdk's before.
Don't bother, I have my own based on asyncio with Real Time API support, pagination and everything. If people interested separating this to it's own package, let me know!
MobileVet|6 years ago
Waterluvian|6 years ago
I think this is an example of a community of nerds forgetting that we're something like 0.1% of a product's userbase.
I think the perpetual anti-electron sentiment is a strong example of how you need to be careful not to listen to just your most vocal customers. Otherwise you might triple your engineering load without even a fraction of practical, real life, measurable benefit.
chrisstpierre|6 years ago
I support the concept of Electron, but my question is - exactly why is it so bloated? Doesn’t it come with a built-in Chromium? Why is that? Wouldn’t it make more sense if it used the machine’s default browser engine? You would need to look out for different browser versions, but we are already doing that for the web anyways.
If not that... then maybe a single electron-specific chromium engine that is shared across electron apps.
paxys|6 years ago
outime|6 years ago
That being said, creating a native app for 2-3 (depends if you include Linux) different OS with completely different frameworks and maintaining feature parity between them involves a lot of specific knowledge and (probably) separate teams. Even if you have a good budget ("infinite resources" is quite arguable) it adds a lot of complexity to something that already has it. All of that just to somehow have a bit more fluent client (but probably much less polished).
The cost for this change would be very, very difficult to justify.
dbbk|6 years ago
longnguyen|6 years ago
I started an open source Slack client but was struggle to find tractions. Yes the Slack electron client is bad, I hate it with passion but it just works. And most of the users I surveyed think so too. Either they’re not using Slack at all, or they just don’t care if it’s electron/web-based/slow (Stockholm syndrome?).
dmitriid|6 years ago
Who says their resources are infinite?
> hasn’t built native clients.
What would it gain them?
underyx|6 years ago
[0]: https://github.com/underyx/url
[1]: https://github.com/underyx/url#5-2019-05-31
omni|6 years ago
josteink|6 years ago
[deleted]
maxdo|6 years ago
zild3d|6 years ago
sc.api_call() with strings for the specific API (there are dozens, each with different inputs) always felt like a temporary ducttape SDK
kissgyorgy|6 years ago
https://github.com/kissgyorgy/gerrit-slack-bot/blob/master/s...
marcinzm|6 years ago
Why not? Theirs has better support behind it and supports everything you listed (RTM api, pagination, async, etc.).
dijit|6 years ago
Excellent, unlike removing a headphone jack; I consider this truly courageous.