Hacker News new | ask | show | jobs
by outime 2582 days 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.

2 comments

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

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.

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

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