Rewriting the Slack Python SDK • Hacker News Board

Re: Rewriting the Slack Python SDK

#21

Post by outime » Sat, Jun 01, 2019, 8:17 PM UTC

MobileVet wrote: post #17

outime wrote: post #6

Earlier quoted context omitted.

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) sep…

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.

Re: Rewriting the Slack Python SDK

#22

Post by BubRoss » Sat, Jun 01, 2019, 11:19 PM UTC

c256 wrote: post #20

BubRoss wrote: post #8

Earlier quoted context omitted.

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

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…

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

Re: Rewriting the Slack Python SDK

#23

Post by giovannibajo1 » Sat, Jun 01, 2019, 11:22 PM UTC

c256 wrote: post #20

BubRoss wrote: post #8

Earlier quoted context omitted.

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

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…

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.

Re: Rewriting the Slack Python SDK

#24

Post by BubRoss » Sat, Jun 01, 2019, 11:22 PM UTC

dmitriid wrote: post #19

BubRoss wrote: post #18

Earlier quoted context omitted.

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.

> First, if it was fast enough, people wouldn't bring up its bloat and speed in every discussion of slack. You should break out of HN bubble > 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. And yet, very few of those thousands of programs are cross-platform…

To be clear, you think all of the following programs look like they were made by a 'high school student' and this is an aspect where electron excels?

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

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

Re: Rewriting the Slack Python SDK

#25

Post by chrisstpierre » Sun, Jun 02, 2019, 3:19 AM UTC

MobileVet wrote: post #4

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

Re: Rewriting the Slack Python SDK

#26

Post by twblalock » Sun, Jun 02, 2019, 7:42 AM UTC

MobileVet wrote: post #17

outime wrote: post #6

Earlier quoted context omitted.

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) sep…

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

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.

Re: Rewriting the Slack Python SDK

#27

Post by threeseed » Sun, Jun 02, 2019, 7:49 AM UTC

twblalock wrote: post #26

MobileVet wrote: post #17

Earlier quoted context omitted.

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

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.

Have you actually used the Slack client before ? It's anything but reliable.

As you would expect from a glorified IRC client that somehow uses 2GB of RAM (lots of accounts).

Re: Rewriting the Slack Python SDK

#28

Post by threeseed » Sun, Jun 02, 2019, 7:54 AM UTC

dmitriid wrote: post #7

MobileVet wrote: post #4

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.

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

Re: Rewriting the Slack Python SDK

#29

Post by twblalock » Sun, Jun 02, 2019, 7:59 AM UTC

threeseed wrote: post #27

twblalock wrote: post #26

Earlier quoted context omitted.

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.

Have you actually used the Slack client before ? It's anything but reliable. As you would expect from a glorified IRC client that somehow uses 2GB of RAM (lots of accounts).

I use the Slack client every day at work on my Mac and it works fine.

It is a lot more than a glorified IRC client —- if that’s all it is, then why has Slack built a successful business?

Re: Rewriting the Slack Python SDK

#30

Post by paxys » Sun, Jun 02, 2019, 8:15 AM UTC

MobileVet wrote: post #4

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.

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?