Rewriting the Slack Python SDK | Hacker News Reader

Rewriting the Slack Python SDK

slack.engineering

50 pointsreinhardt54 comments

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

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

> It could be written once in C++ using Qt, Juce, or Fltk and be blazingly fast.

So, it was written once using Electron and is sufficiently fast.

> This has been done thousands of times over the last few decades. Where does this myth come from?

There are surprisingly few cross platform apps written using these technologies that are fast, functional and have any degree of visual polish.

Neither of these things are true and there is enormous evidence.

First, if it was fast enough, people wouldn't bring up its bloat and speed in every discussion of slack.

Second, there are hundreds if not thousands of programs much more complicated than slack that work exceptionally well and have been made with these GUI libraries. A minimal amount of searching would show this.

I can’t think of any applications written using those (or any other, actually) cross-platform toolkits for Windows, macOS, Linux, iOS, and Android that were even moderately successful in the market. Generally, cross-platform UIs are disliked or hated everywhere; sometimes with the exception that they’re considered decent in their one truly native environment and terrible elsewhere. Qt definitely falls into this group.

Can you suggest a couple examples? I’m no fan of Electron, but I don’t see it as being so easily replaced as you seem to be suggesting.

https://en.m.wikipedia.org/wiki/Qt_(software)#Applications_u...

Some notable programs:

Adobe Photoshop Album, Adobe Photoshop Elements, AMD's driver tool, CryEngine, Autodesk Maya, Google Earth, Mathematica, Opera, OBS, Skype, Teamviewer, Telegram, VLC media player, Wireshark, QtCreator, Qbittorrent, Nuke, Xnview

You’re thinking of a timeframe in which apps embraced native style of operating systems. Slack does not do that, it’s a web app with a custom UI that doesn’t feel native on any OS. Thus, it would be perfectly sensible to rewrite it once in QML with a single codebase.

If anything, the main objection should be difficulty of hiring QML developers compared to JavaScript/CSS.

Doesn't the success of Slack counter your whole point? It is built using a cross-platform toolkit for Windows, macOS and Linux, and is to some degree disliked or hated everywhere for the same reasons that Qt might be.

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

If we play the guessing game I'd assume they'd like to make more money, and doing what it's been suggested on this thread is most likely not going to provide any benefit for Slack but more like the opposite.

To make my point clear, I don't believe the current app is so terrible (performance-wise) that's making Slack lose any significant amount of users/revenue.

On the other hand, adding new features to the (cross-platform) app, fixing bugs, etc in a timely fashion will help the business. I'd also include polishing here but rewriting the whole application from scratch for different OS is, IMHO, not worth it.

They have all of that money because they have made good decisions about their product so far. They focus on what matters most to users: features and reliability, not the framework the UI was written in.

Profitable decisions you mean.

> with its infinite resources

Who says their resources are infinite?

> hasn’t built native clients.

What would it gain them?

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.

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

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.

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.

> We want web apps to work as well as Native applications

This is fundamentally impossible.

Why?

Not the parent, but I suppose he is referring to the fact that it’s another layer of indirection, and solve different problems.

It’s akin to saying “we want C to work as well as ASM”, which is kind of like comparing apples to oranges.

That’s not what I mean, really. Chrome book already has a non-negligible market share. Practically everything is a “web app” already. Sure, there are going to be use cases for lower level native software, but in reference to Electron I think it’s obvious that we are better off getting things to run better in the first place. Obviously Browsers weren’t originally designed to work this way, but it’s just how things have turned out. And developers are very familiar with html/css/JavaScript.

But of course getting the major browsers to play along has always been slow Microsoft as mentioned already.

But I understand why it makes sense to skip Electron in its current state

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?

Blender, Kdenlive, Gimp.

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.

Telegram desktop is very fast

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

Those either are not single-codebase-crossplatform or are architectured like a game engine. Yes Electron is not optimal but if you want a "rich" UI with fancy animations and custom interfaces for everything instead of a generic winforms-style UX then the browser is a good compromise. That or feel free to manually build everything using OpenGL/Godot/Unity. (Using a browser means you are shifting all the game-engine-level graphics requirement to a billion dollar company. The problem doesn't actually magically go away.

(And to be fair, UI development in XAML on Windows is not too different from HTML/CSS/JS i.e. no Drag and Drop absolute positioning, everything is relative with a constraint system bolted on top.)

Adobe and Microsoft are orders of magnitude bigger than Slack, so it isn't really the best comparison. And none of those apps support Linux.

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.

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.

Maybe you're right. We would have to measure first. Otherwise we are just doing another thing I hate witnessing: the nerds insisting to the non-nerds that they actually have a problem.

This reminds me of an opinion I heard about why not to do full body scans: you'll inevitably find diagnoses that don't actually matter but will affect the patient's quality of life just by being aware of and inevitably defined by their conditions.

Hmm. On reflection I think this is closely related: treat the patient not the problem.

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

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.

I'm not entirely sure, that why I put a question mark on it. Some of the users I surveyed are devs themselves and to my surprise, they think Electron is good. I've just read this article[1] and I think it's best to describe the situation of being a JS dev

[1]: https://medium.com/@s_27669/i-am-definitely-maybe-suffering-...

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

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

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

They are, but not for an API wrapper.

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.

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

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

>Don't bother

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

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

And again, you make statements and don't provide any data to back them up. If there's issues with their API which yours doesn't have then describe or list them.

edit: You also conveniently change your argument once I point out the previous one doesn't hold up.

yours just has a bunch of print statements, several FIXME's, some weird choices (throwing an ApiError in one case but just printing the error in another), random things like a half baked Emoji enum (make this dynamic) and isn't a library you can pip install.

The code is quite clean though.

They're rewriting with py3 in mind?

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

Reply on news.ycombinator.com