4 ms·

For what it’s worth, all of the arguments against your choices are inadequate and don’t really wrestle with the complexity of the domain. And I suspect the auth

For what it’s worth, all of the arguments against your choices are inadequate and don’t really wrestle with the complexity of the domain. And I suspect the authors are not considering this as though they’d be the one responsible for making these decisions for a company like Slack themselves.

saagarjha 8y ago
Fun fact: Slack has native iOS and Android apps, with all their platform-independent logic abstracted away in a C++ library. I see no “complexity” in making a native macOS app with this.
- jf- 8y ago
  From a cost-benefit point of view there’s nothing in it for slack. They’d have to rewrite and maintain three separate versions of the same app they already have, and what would the payoff be? It would mildly please a handful of bellyachers, who would then immediately move on to the next grievance. For the majority of users it would be wasted money and effort.
  - apple4ever 8y ago
    There sure is. They've have an app that doesn't suck for one. Which you know, would help conversions. Its not hard to write a Mac app, and its even easier to maintain it. ESPECIALLY if you already have an iOS app. There is no reason not to just make a decent Mac app. NONE.
    - jf- 8y ago
      Using caps isn’t a substitute for having a point, nor is it a refutation of the effort involved to make three separate native apps instead of one. Also you’re not supposed to use caps here. I don’t think it sucks, most users don’t think it sucks. You represent a tiny, vocal minority.
  - saagarjha 8y ago
    My argument is that this is not actually all that much effort, and it would make far more people happy than you’d realize. While not everyone can verbalize their complaints about Slack, I’m sure many feel the performance issues; and they would certainly notice if Slack happened to load five seconds faster or their computer’s battery lasted a couple of hours longer.
    - jf- 8y ago
      I think you’re underestimating the work involved, plus switching from electron to native won’t make people’s battery last hours longer.
      - saagarjha 8y ago
        > I think you’re underestimating the work involved This was the amount of work necessary for me to ditch running Slack in a Safari tab, and basically consists of being able to talk to people and send them attachments–the things I do 99% of the time. If I need something advanced like voice calling I’m more than happy to fire up actual Slack. Assuming libslack (or whatever it is called) handles the core protocol and communication layer, I don’t see why it would be difficult to write a bit of Cocoa code around it; I could even pull some of this straight from the iOS app. > switching from electron to native won’t make people’s battery last hours longer It does, though. Opening Slack on my computer reduces the battery life by around two hours; a well made native app will have a reduction that can be measured in minutes. Native apps are just better at idling and using fewer resources when they are in active use.
        ec109685 8y ago
        Which application as complicated as slack do you run 24x7 on your computer, with a persistent connection to a server updating the ui that only reduces your battery by a few minutes versus two hours with slack?
- giobox 8y ago
  Do people still regularly try to ship common platform code as a shared C++ library to minimise unique code bases for their mobile apps? I recall reading years ago Dropbox trying this, but in 2018 is this really the best approach we have? I can see why it might potentially be attractive in purely architectural terms, but I wonder if the “savings” meaningfully materialise in practice when so little pure native development occurs in C++ on iOS and Android. Regardless, there’s still a complexity cost - unique native platform UI code is still unique native code, plus all the localisation, QA testing, etc, etc fun that will entail for an app the size of Slack.
  - jarjoura 8y ago
    Facebook shares a huge chunk of core code between Android and iOS with C++. Even with Electron, VS Code also writes a lot of the core modules in C++. At the end of the day, it's just a clever way to write performant code that can be shared.
  - saagarjha 8y ago
    > Do people still regularly try to ship common platform code as a shared C++ library to minimise unique code bases for their mobile apps? I think Microsoft Office does this too, and I’m pretty pleased with the results, performance and UI wise. In my opinion, this is probably the best way to actually do decent cross-platform development. One of the projects that I am tangentially involved in is doing this, but swapping out C++ with Rust. > I recall reading years ago Dropbox trying this Last I heard, Dropbox has moved towards using Python for everything, which gives them kinda horrible performance IMO. > I can see why it might potentially be attractive in purely architectural terms, but I wonder if the “savings” meaningfully materialise in practice when so little pure native development occurs in C++ on iOS and Android. Generally, all the cross-platform, UI independent bits go into the framework, and then you write a thin UI layer on top of it using your platform’s native UI APIs. The benefit of using C++ is that you can call it easily from most languages. > Regardless, there’s still a complexity cost - unique native platform UI code is still unique native code, plus all the localisation, QA testing, etc, etc fun that will entail for an app the size of Slack. Ok, sure, but most of this work has already been done for their iOS app. I’m making a shot in the dark here, but I’d think that given access to their iOS project I could whip up something passable within a couple of months, if not less.

saagarjha 8y ago

Fun fact: Slack has native iOS and Android apps, with all their platform-independent logic abstracted away in a C++ library. I see no “complexity” in making a native macOS app with this.

jf- 8y ago
From a cost-benefit point of view there’s nothing in it for slack. They’d have to rewrite and maintain three separate versions of the same app they already have, and what would the payoff be? It would mildly please a handful of bellyachers, who would then immediately move on to the next grievance. For the majority of users it would be wasted money and effort.
- apple4ever 8y ago
  There sure is. They've have an app that doesn't suck for one. Which you know, would help conversions. Its not hard to write a Mac app, and its even easier to maintain it. ESPECIALLY if you already have an iOS app. There is no reason not to just make a decent Mac app. NONE.
  - jf- 8y ago
    Using caps isn’t a substitute for having a point, nor is it a refutation of the effort involved to make three separate native apps instead of one. Also you’re not supposed to use caps here. I don’t think it sucks, most users don’t think it sucks. You represent a tiny, vocal minority.
- saagarjha 8y ago
  My argument is that this is not actually all that much effort, and it would make far more people happy than you’d realize. While not everyone can verbalize their complaints about Slack, I’m sure many feel the performance issues; and they would certainly notice if Slack happened to load five seconds faster or their computer’s battery lasted a couple of hours longer.
  - jf- 8y ago
    I think you’re underestimating the work involved, plus switching from electron to native won’t make people’s battery last hours longer.
    - saagarjha 8y ago
      > I think you’re underestimating the work involved This was the amount of work necessary for me to ditch running Slack in a Safari tab, and basically consists of being able to talk to people and send them attachments–the things I do 99% of the time. If I need something advanced like voice calling I’m more than happy to fire up actual Slack. Assuming libslack (or whatever it is called) handles the core protocol and communication layer, I don’t see why it would be difficult to write a bit of Cocoa code around it; I could even pull some of this straight from the iOS app. > switching from electron to native won’t make people’s battery last hours longer It does, though. Opening Slack on my computer reduces the battery life by around two hours; a well made native app will have a reduction that can be measured in minutes. Native apps are just better at idling and using fewer resources when they are in active use.
      - ec109685 8y ago
        Which application as complicated as slack do you run 24x7 on your computer, with a persistent connection to a server updating the ui that only reduces your battery by a few minutes versus two hours with slack?
giobox 8y ago
Do people still regularly try to ship common platform code as a shared C++ library to minimise unique code bases for their mobile apps? I recall reading years ago Dropbox trying this, but in 2018 is this really the best approach we have? I can see why it might potentially be attractive in purely architectural terms, but I wonder if the “savings” meaningfully materialise in practice when so little pure native development occurs in C++ on iOS and Android. Regardless, there’s still a complexity cost - unique native platform UI code is still unique native code, plus all the localisation, QA testing, etc, etc fun that will entail for an app the size of Slack.
- jarjoura 8y ago
  Facebook shares a huge chunk of core code between Android and iOS with C++. Even with Electron, VS Code also writes a lot of the core modules in C++. At the end of the day, it's just a clever way to write performant code that can be shared.
- saagarjha 8y ago
  > Do people still regularly try to ship common platform code as a shared C++ library to minimise unique code bases for their mobile apps? I think Microsoft Office does this too, and I’m pretty pleased with the results, performance and UI wise. In my opinion, this is probably the best way to actually do decent cross-platform development. One of the projects that I am tangentially involved in is doing this, but swapping out C++ with Rust. > I recall reading years ago Dropbox trying this Last I heard, Dropbox has moved towards using Python for everything, which gives them kinda horrible performance IMO. > I can see why it might potentially be attractive in purely architectural terms, but I wonder if the “savings” meaningfully materialise in practice when so little pure native development occurs in C++ on iOS and Android. Generally, all the cross-platform, UI independent bits go into the framework, and then you write a thin UI layer on top of it using your platform’s native UI APIs. The benefit of using C++ is that you can call it easily from most languages. > Regardless, there’s still a complexity cost - unique native platform UI code is still unique native code, plus all the localisation, QA testing, etc, etc fun that will entail for an app the size of Slack. Ok, sure, but most of this work has already been done for their iOS app. I’m making a shot in the dark here, but I’d think that given access to their iOS project I could whip up something passable within a couple of months, if not less.