4 ms·

do you really though

by comboy 8y ago

benbristow 8y ago
If it makes for easier programming, yes. Writing Slack as a native app would be a massive pain. Especially due to all the web-like features it has, the fact that it's one codebase (mainly) for desktop and web. They also have to support Windows, Linux, Mac and mobile. Not an easy task
- LeoNatan25 8y ago
  For a billion dollar company? Give me a break.
  - true_religion 8y ago
    Slacks annual revenue was 200 million in 2017, when they were a 5 billion dollar valued company. 200 mil is just 1000 Bay Area salaries, and they do have other budget items. Its entirely possible that they cannot fund 5 native development teams, while building their core features to justify their valuation, and paying their sales and marketting team to actually generate revenue.
    - CyberDildonics 8y ago
      I legitimately can't tell if you are joking.
      - LeoNatan25 8y ago
        It does sound like a joke. It also ignores that fact that other, proper, multiplatform technologies exist that still produce a far superior end result for the user even if not 100% platform guidelines/conventions compliant.
    - flukus 8y ago
      5 Devs on each team, which should be more than enough if they're getting 200k a year would cost a total of 5 mil. A tiny amount for such a huge improvement for users.
  - vntok 8y ago
    What do you mean? Slack is valued at ~5 billion dollars, that has very little to do with their actual cash on hand. In 2016, they were bringing less than 65 million in revenue, for example.
- Razengan 8y ago
  There are more complex apps with native versions for multiple platforms, by smaller companies.
  - jonny_eh 8y ago
    Such as?
    - ForHackernews 8y ago
      LibreOffice has native versions for all major desktop platforms, does many more things than Slack, and is maintained by open source volunteers and the Document Foundation staff of six.
    - Razengan 8y ago
      Affinity Designer, Photo, and Publisher to name a few, from the same company. [0] Then there are many games, which by their nature require native performance, and of course have to present the same frontend. :) [0] https://affinity.serif.com https://affinity.serif.com
      - lazerwalker 8y ago
        Games feel like a separate edge case. One of the most common complaints about cross-platform apps is they don't "feel native" or adhere to platform UX expectations. With games, there's an expectation they'll provide their own wholly own UI that doesn't match an existing commercial OS.
        mwcampbell 8y ago
        Also, video games aren't generally expected to be accessible to blind people via screen readers. If you develop a cross-platform app with a custom UI, it's going to have zero accessibility unless you implement each platform's accessibility API.
        Razengan 8y ago
        Yes, game devs already put in the effort of providing their own UI stack, and port that to every OS. If most Electron apps were built as "games", i.e. providing their own UI via DirectX/OpenGL/Metal etc., I wonder if they might still be more efficient and less bloated than Electron apps are now.
- comboy 8y ago
  I think I like when programming is hard. When you're working on your own project, some time sink that you didn't anticipate may be frustrating, but other than that, I definitely prefer it to coding something I already know how to do well.
- rudedogg 8y ago
  > Writing Slack as a native app would be a massive pain. If it was allowed I'd write the native macOS app for them. I'm sure it'd pay off selling it for $5 or $10 in the Mac App Store
  - danShumway 8y ago
    Do it then: https://api.slack.com/ https://api.slack.com/ Slack APIs aren't perfect, but they're good enough to allow 3rd party clients for terminals, Emacs[0], and the like. I've never dug into it because I avoid Slack in general, but I think the biggest hurdle right now is just user authentication. That's a pain, and does limit your audience, but maybe you'd still find some buyers on HN. [0]: https://github.com/yuya373/emacs-slack https://github.com/yuya373/emacs-slack
    - benbristow 8y ago
      OAuth2 is as standard as it gets. Any language worth it's salt has ready-made libraries for it. There's tons of documentation and guides online too. Not sure why that's an issue.
- kitsunesoba 8y ago
  The Mac cocoa version of Telegram achieves most of the same features as slack without resorting to webviews and shares 99% of its code with the iOS app (meaning the Mac build adds practically no overhead). Windows and Linux are another beast, and Telegram’s solution is to use Qt for those platforms. Again, slack like capabilities with no webviews. The difficulty of native dev is not as high as it’s often represented.
  - mercer 8y ago
    I have little experience with native iOS development, so you might well be right. That said, Telegram strikes me as quite a bit simpler than Slack. Not just in number of features, but also considering how many of the features are 'strange' UI. As an aside, apparently the next version of Telegram will be a complete rewrite done in Swift, and snappier as a result.

do you really though

by comboy 8y ago

do you really though

If it makes for easier programming, yes. Writing Slack as a native app would be a massive pain. Especially due to all the web-like features it has, the fact that it's one codebase (mainly) for desktop and web. They also have to support Windows, Linux, Mac and mobile. Not an easy task

LeoNatan25 8y ago
For a billion dollar company? Give me a break.
- true_religion 8y ago
  Slacks annual revenue was 200 million in 2017, when they were a 5 billion dollar valued company. 200 mil is just 1000 Bay Area salaries, and they do have other budget items. Its entirely possible that they cannot fund 5 native development teams, while building their core features to justify their valuation, and paying their sales and marketting team to actually generate revenue.
  - CyberDildonics 8y ago
    I legitimately can't tell if you are joking.
    - LeoNatan25 8y ago
      It does sound like a joke. It also ignores that fact that other, proper, multiplatform technologies exist that still produce a far superior end result for the user even if not 100% platform guidelines/conventions compliant.
  - flukus 8y ago
    5 Devs on each team, which should be more than enough if they're getting 200k a year would cost a total of 5 mil. A tiny amount for such a huge improvement for users.
- vntok 8y ago
  What do you mean? Slack is valued at ~5 billion dollars, that has very little to do with their actual cash on hand. In 2016, they were bringing less than 65 million in revenue, for example.
Razengan 8y ago
There are more complex apps with native versions for multiple platforms, by smaller companies.
- jonny_eh 8y ago
  Such as?
  - ForHackernews 8y ago
    LibreOffice has native versions for all major desktop platforms, does many more things than Slack, and is maintained by open source volunteers and the Document Foundation staff of six.
  - Razengan 8y ago
    Affinity Designer, Photo, and Publisher to name a few, from the same company. [0] Then there are many games, which by their nature require native performance, and of course have to present the same frontend. :) [0] https://affinity.serif.com https://affinity.serif.com
    - lazerwalker 8y ago
      Games feel like a separate edge case. One of the most common complaints about cross-platform apps is they don't "feel native" or adhere to platform UX expectations. With games, there's an expectation they'll provide their own wholly own UI that doesn't match an existing commercial OS.
      - mwcampbell 8y ago
        Also, video games aren't generally expected to be accessible to blind people via screen readers. If you develop a cross-platform app with a custom UI, it's going to have zero accessibility unless you implement each platform's accessibility API.
      - Razengan 8y ago
        Yes, game devs already put in the effort of providing their own UI stack, and port that to every OS. If most Electron apps were built as "games", i.e. providing their own UI via DirectX/OpenGL/Metal etc., I wonder if they might still be more efficient and less bloated than Electron apps are now.
comboy 8y ago
I think I like when programming is hard. When you're working on your own project, some time sink that you didn't anticipate may be frustrating, but other than that, I definitely prefer it to coding something I already know how to do well.
rudedogg 8y ago
> Writing Slack as a native app would be a massive pain. If it was allowed I'd write the native macOS app for them. I'm sure it'd pay off selling it for $5 or $10 in the Mac App Store
- danShumway 8y ago
  Do it then: https://api.slack.com/ https://api.slack.com/ Slack APIs aren't perfect, but they're good enough to allow 3rd party clients for terminals, Emacs[0], and the like. I've never dug into it because I avoid Slack in general, but I think the biggest hurdle right now is just user authentication. That's a pain, and does limit your audience, but maybe you'd still find some buyers on HN. [0]: https://github.com/yuya373/emacs-slack https://github.com/yuya373/emacs-slack
  - benbristow 8y ago
    OAuth2 is as standard as it gets. Any language worth it's salt has ready-made libraries for it. There's tons of documentation and guides online too. Not sure why that's an issue.
kitsunesoba 8y ago
The Mac cocoa version of Telegram achieves most of the same features as slack without resorting to webviews and shares 99% of its code with the iOS app (meaning the Mac build adds practically no overhead). Windows and Linux are another beast, and Telegram’s solution is to use Qt for those platforms. Again, slack like capabilities with no webviews. The difficulty of native dev is not as high as it’s often represented.
- mercer 8y ago
  I have little experience with native iOS development, so you might well be right. That said, Telegram strikes me as quite a bit simpler than Slack. Not just in number of features, but also considering how many of the features are 'strange' UI. As an aside, apparently the next version of Telegram will be a complete rewrite done in Swift, and snappier as a result.