Rewriting the Slack Python SDK

https://slack.engineering/rewriting-the-slack-python-sdk-ea000f587de7

by reinhardt • 7 years ago

50 47 7 years ago

kissgyorgy2• 7 years ago

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!

https://github.com/kissgyorgy/gerrit-slack-bot/blob/master/s...

marcinzm2• 7 years ago

Don't bother

Why not? Theirs has better support behind it and supports everything you listed (RTM api, pagination, async, etc.).

kissgyorgy2• 7 years ago

It's API is actually terrible and has bugs which mine don't.

dijit• 7 years ago

They're rewriting with py3 in mind?

Excellent, unlike removing a headphone jack; I consider this truly courageous.

MobileVet2• 7 years ago

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.

outime2• 7 years ago

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.

BubRoss3• 7 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.

Why do people believe this? It could be written once in C++ using Qt, Juce, or Fltk and be blazingly fast. This has been done thousands of times over the last few decades. Where does this myth come from?

MobileVet2• 7 years ago

They literally have 100s of millions of dollars in cash. What else should they do with that money besides polish their product?

dmitriid2• 7 years ago

with its infinite resources

Who says their resources are infinite?

hasn’t built native clients.

What would it gain them?

threeseed• 7 years ago

In my case native clients would use anywhere from 1/10th - 1/100th the resources.

And everyday the app will freeze for 5-10 seconds at a time on a 2018 MacBook Pro.

So Slack really only does 1 thing which is a chat app and if they can't do that properly then you have to wonder.

dbbk• 7 years ago

They're focusing on removing Electron by switching to Desktop PWAs.

chrisstpierre2• 7 years ago

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.

deeringc• 7 years ago

On Windows that currently means MSHTML which, depending on your OS version means some variant of IE. Not even Microsoft pages support IE properly anymore. Also, bloated here tends to mean runtime cost, RAM and CPU use, not disk use which is what you are solving for. Some browsers are definitely worse than others in this respect but running several instances of a full browser stack is not exactly light for any of the major browser engines.

SomeOldThrow3• 7 years ago

We want web apps to work as well as Native applications

This is fundamentally impossible.

paxys2• 7 years ago

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?

throwaway5d097• 7 years ago

Blender, Kdenlive, Gimp.

SomeOldThrow3• 7 years ago

They’re apparently quite valuable and definitely quite rich. The typical issues of cross platform development is far below their pay grade. The better answer is they simply don’t care about the needs of their end users because they sell to management and it would bring profits down to feign interest.

Also, you could have googled this.

elcomet• 7 years ago

Telegram desktop is very fast

Nextgrid2• 7 years ago

Adobe Photoshop & its friends? Microsoft Office? Just a few examples, I'm sure there's plenty more.

Waterluvian2• 7 years ago

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.

Nextgrid2• 7 years ago

Just because nerds complain doesn't mean doesn't mean "non-nerds" aren't suffering from the same problem except they don't have the technical knowledge to blame it on Slack using Electron, so when their computer is sluggish or runs out of battery in half the expected time they'd just blame it on something else, but the problem itself doesn't magically go away.

longnguyen2• 7 years ago

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?).

hoffs• 7 years ago

What does Stockholm syndrome have to do with people being okay with the performance of it. The only people that mostly have issue with slack are the devs themselves who are aware of electron.

benatkin• 7 years ago

Slack is against alternative clients, just like Twitter is. So it's risky to build a client because they can limit API access.

underyx2• 7 years ago

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]

[0] https://github.com/underyx/url

[1] https://github.com/underyx/url#5-2019-05-31

omni• 7 years ago

C extensions are a pretty common thing in the Python ecosystem, you're making this sound a lot more drastic than it is

underyx2• 7 years ago

They are, but not for an API wrapper.

zild3d• 7 years ago

Happy about this, writing a slack app/bot with the old SDK was often opaque

sc.api_call() with strings for the specific API (there are dozens, each with different inputs) always felt like a temporary ducttape SDK

maxdo• 7 years ago

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.

Rewriting the Slack Python SDK

Related Stories