7 ms·

Because "time to ship", "availability" and "discoverability" are much more important concerns to many business than "consistency with the UI conventions of a gi

Because "time to ship", "availability" and "discoverability" are much more important concerns to many business than "consistency with the UI conventions of a given desktop operating system". * "Time to ship" Going the "native" way for desktops means doing specific work for Windows X, Windows Y, Windows Z, MacOs Whatever, than MacOs Whatever-Beta-Plus. Even using the "write one, use everywhere" framework entices such work, because of the dirty secret no one talks about : they don't really work besides simple apps. The choice of leaving those problems to the Chrome team is _really_ tempting. * Availability Popular Desktop OS have not historically integrated "app stores" or "canonical way to install an app". Asking them to "Install" stuff is great if they're nostalgic geeks like us ; but real people learned long ago that anything asking the right to "install" on their computer is malware from a shaddy gambling website. * Discoverability People don't care about your app. Really, they don't. But they have chrome on their computer (it came preinstalled, and they need it for Facebook), so at least you get a chance to grow your user base if you manage to put a link to your website in your facebook feed, or, if they're high-tech users, as an ad on the top of their google search result (also knows as "the internet".) The only exception, as usual, is games, because: * they need to run native code and can't afford the dozen layers of inderection of a browser * their users are dedicated nerds who will happily glue toxic chemical products to the CPU of their opened motherboards in order to get 1 more frame per seconds * the install process of game exists, it's called Steam

MattGaiser 5y ago
> Asking them to "Install" stuff is great if they're nostalgic geeks like us ; but real people learned long ago that anything asking the right to "install" on their computer is malware from a shaddy gambling website. Or just the limitations of permissions. A business team can adopt a SaaS unilaterally. Anything installed involves IT.
- mjevans 5y ago
  This is why the runtime libraries __have__ to be shipped by the OS vendor. It isn't good enough that Windows (or OSX for that matter) includes only stuff for it's OS. It should include a standard that is compatible with every other major platform too. We don't even really get that with Electron either; all of those apps are 'fat' in that they ship the entire standard library for doing anything with 'Hello World'.
- mywittyname 5y ago
  > A business team can adopt a SaaS unilaterally. Anything installed involves IT. That's changing with SSO. Security and compliance teams are cracking down on rogue BUs buying SaaS products willy-nilly.
  - marcosdumay 5y ago
    Ok, I guess "BU" here means "business unity" (I can't remember ever seeing that term), but I can't imagine what "SSO" could be that would crack-down on people signing on internet services.
    - boojums 5y ago
      Business Unit and Single Sign On most likely
      - marcosdumay 5y ago
        Yeah, Single Sign On is an acronym I know, but can't do anything like the GP's claim.
        phtrivier 5y ago
        I guess the claim is that, if you want your little team in MegaCorp to use a little Sass app, you're going to have to either : - create user accounts at LittleApp, with your personal email, and have to remember a password. Then, you're potentially giving sensitive corporate info to the SaaS app, with your personal email, and you risk getting fired for that. Plus,new passwords are annoying ! - so you try integrating with the SSO solution from your MegaCorp, which means you have to talk to IT. Which means: A/ you're going to have to wait because they're busy telling people to switch it off an on again ; B/ they're now in a position to exert power over a decision you would like to make. Politics will ensue.
        marcosdumay 5y ago
        Oh, ok, that makes sense. But there are a couple of fixes. You create the account with your corporate email. You just need the password. And that part: you're potentially giving sensitive corporate info to the SaaS app, with your personal email, and you risk getting fired for that If that one part is real, than SSO isn't adding any power to you (or to the DSO anyway). If it isn't, then the only thing SSO changes is the password one.
throw10920 5y ago
If "time to ship" is actually important, than why do most companies go to the work of making three separate codebases for their applications - Android, iOS, and web? As to "availability", desktop app stores have become more prevalent over time, not less - which means that if this actually were a contributing factor, you would see more developers and people using desktop software, not less. And as to "discoverability", there's no mutual exclusion between a webapp and a native application - in fact, the two values add. Making both makes your application strictly more discoverable. All of these reasons seem somewhat disconnected from reality. I'm pretty sure the reason is simpler: companies want to get the highest ratio of revenue/users to development costs that they can (regardless of the negative externalities toward users e.g. performance and UX), and the trifecta of Android+iOS+webapp (combined with the fact that consumers now accept web applications in lieu of desktop ones) allows them to do that.
- ozzythecat 5y ago
  > If "time to ship" is actually important, than why do most companies go to the work of making three separate codebases for their applications - Android, iOS, and web? In my experience at a FANG company, it turns out that building and supporting three separate code bases is (counterintuitively) faster and more productive than a unified code base. We took a stab at this using Reactive Native and C++. It’s been a couple years at least since we did this, and so disclaimer: this might not be the case today. I am also no longer with that company. The developers hated using RN. In 80% of the use cases, everything worked ok. The other 20% of the use cases consumed 90% of the teams time, and we effectively had to hire engineers who were experts in iOS, android, AND now react native. Meanwhile, the total amount of time to launch a new feature did not decrease. Our C++ path had its own problems. Building dependencies across different architectures was a nightmare at times. My organization didn’t really have C++ developers. Surprisingly this didn’t really slow us down, and we quickly worked around the learning curve. This worked for us because we weren’t writing low level system code but just business logic. When it came time to integrate into our iOS applications and several android applications, we again ran into build issues. We had many copy and pasted CMake scripts, which no one really understood and no one really wanted to maintain and own. This was frustrating enough that we experienced significant turnover, and we lost very valuable teammates. In hindsight, we took both of these paths inorganically. These decisions were made by senior staff engineers and upper level management. It pissed off a lot of developers and lead to a lot of turnover. I have friends at that company, and they are again thinking about going back in the same direction.
deleted 5y ago
[deleted]
MonaroVXR 5y ago
>Even using the "write one, use everywhere" framework entices such work, because of the dirty secret no one talks about : they don't really work besides simple apps. Do you have examples? I'm not using many apps I guess.
CRConrad 5y ago
> Going the "native" way for desktops means doing specific work for Windows X, Windows Y, Windows Z ... Windows XP apps run fine on Windows 11, AFAIK, so that's a totally bogus argument.

MattGaiser 5y ago

> Asking them to "Install" stuff is great if they're nostalgic geeks like us ; but real people learned long ago that anything asking the right to "install" on their computer is malware from a shaddy gambling website. Or just the limitations of permissions. A business team can adopt a SaaS unilaterally. Anything installed involves IT.

mjevans 5y ago
This is why the runtime libraries __have__ to be shipped by the OS vendor. It isn't good enough that Windows (or OSX for that matter) includes only stuff for it's OS. It should include a standard that is compatible with every other major platform too. We don't even really get that with Electron either; all of those apps are 'fat' in that they ship the entire standard library for doing anything with 'Hello World'.
mywittyname 5y ago
> A business team can adopt a SaaS unilaterally. Anything installed involves IT. That's changing with SSO. Security and compliance teams are cracking down on rogue BUs buying SaaS products willy-nilly.
- marcosdumay 5y ago
  Ok, I guess "BU" here means "business unity" (I can't remember ever seeing that term), but I can't imagine what "SSO" could be that would crack-down on people signing on internet services.
  - boojums 5y ago
    Business Unit and Single Sign On most likely
    - marcosdumay 5y ago
      Yeah, Single Sign On is an acronym I know, but can't do anything like the GP's claim.
      - phtrivier 5y ago
        I guess the claim is that, if you want your little team in MegaCorp to use a little Sass app, you're going to have to either : - create user accounts at LittleApp, with your personal email, and have to remember a password. Then, you're potentially giving sensitive corporate info to the SaaS app, with your personal email, and you risk getting fired for that. Plus,new passwords are annoying ! - so you try integrating with the SSO solution from your MegaCorp, which means you have to talk to IT. Which means: A/ you're going to have to wait because they're busy telling people to switch it off an on again ; B/ they're now in a position to exert power over a decision you would like to make. Politics will ensue.
        marcosdumay 5y ago
        Oh, ok, that makes sense. But there are a couple of fixes. You create the account with your corporate email. You just need the password. And that part: you're potentially giving sensitive corporate info to the SaaS app, with your personal email, and you risk getting fired for that If that one part is real, than SSO isn't adding any power to you (or to the DSO anyway). If it isn't, then the only thing SSO changes is the password one.

throw10920 5y ago

If "time to ship" is actually important, than why do most companies go to the work of making three separate codebases for their applications - Android, iOS, and web? As to "availability", desktop app stores have become more prevalent over time, not less - which means that if this actually were a contributing factor, you would see more developers and people using desktop software, not less. And as to "discoverability", there's no mutual exclusion between a webapp and a native application - in fact, the two values add. Making both makes your application strictly more discoverable. All of these reasons seem somewhat disconnected from reality. I'm pretty sure the reason is simpler: companies want to get the highest ratio of revenue/users to development costs that they can (regardless of the negative externalities toward users e.g. performance and UX), and the trifecta of Android+iOS+webapp (combined with the fact that consumers now accept web applications in lieu of desktop ones) allows them to do that.

ozzythecat 5y ago
> If "time to ship" is actually important, than why do most companies go to the work of making three separate codebases for their applications - Android, iOS, and web? In my experience at a FANG company, it turns out that building and supporting three separate code bases is (counterintuitively) faster and more productive than a unified code base. We took a stab at this using Reactive Native and C++. It’s been a couple years at least since we did this, and so disclaimer: this might not be the case today. I am also no longer with that company. The developers hated using RN. In 80% of the use cases, everything worked ok. The other 20% of the use cases consumed 90% of the teams time, and we effectively had to hire engineers who were experts in iOS, android, AND now react native. Meanwhile, the total amount of time to launch a new feature did not decrease. Our C++ path had its own problems. Building dependencies across different architectures was a nightmare at times. My organization didn’t really have C++ developers. Surprisingly this didn’t really slow us down, and we quickly worked around the learning curve. This worked for us because we weren’t writing low level system code but just business logic. When it came time to integrate into our iOS applications and several android applications, we again ran into build issues. We had many copy and pasted CMake scripts, which no one really understood and no one really wanted to maintain and own. This was frustrating enough that we experienced significant turnover, and we lost very valuable teammates. In hindsight, we took both of these paths inorganically. These decisions were made by senior staff engineers and upper level management. It pissed off a lot of developers and lead to a lot of turnover. I have friends at that company, and they are again thinking about going back in the same direction.

deleted 5y ago

[deleted]

MonaroVXR 5y ago

>Even using the "write one, use everywhere" framework entices such work, because of the dirty secret no one talks about : they don't really work besides simple apps. Do you have examples? I'm not using many apps I guess.

CRConrad 5y ago

> Going the "native" way for desktops means doing specific work for Windows X, Windows Y, Windows Z ... Windows XP apps run fine on Windows 11, AFAIK, so that's a totally bogus argument.