4 ms·

An alternative: a native app.

by hdjjhhvvhga 5y ago

endisneigh 5y ago
native to what?
- j1elo 5y ago
  The word "native" has diluted in a sea of abstractions and supporting technologies, but in this context I'd read "native app" as removing the browser engine layer (so, not even really native by far, but much closer to the OS and hardware than when writing code on top of the mentioned layer)
  - hdjjhhvvhga 5y ago
    Yes. Putting an app in a browser has solved tens of problems and introduced a hundred new ones. At some point you start to wonder if a plain old native app wouldn't work much better that an uncontrollably growing stack of technologies, some ow which designed for something completely different than what we're trying to accomplish.
    - hunterb123 5y ago
      Okay. You still need a client side database with syncing. Which is what this is about. The pure native approach only solves (kind of) the limited storage issues, nothing else. If you nuke your site and only develop about native apps then you'll lose users to competitors because people can try their service without downloading an app. Yeah maybe we shouldn't have shoved an app run-time into a document viewer, but here we are and things run decently well (thanks to v8 and other tech) if you do things right.
      - hdjjhhvvhga 5y ago
        I think you underestimate the number of issues a (purely) native app solves. The fact that many developers don't care about some of them it does not mean they don't exist. One of them is shorter delay, very important in interactive applications. Syncing can be implemented in billion ways, from dedicated solutions to custom ones. Paradoxically, I think Microsoft got it (somewhat) right with Office. You can use a native C++ app, and this is what most people use because of speed and control. However, if you like working online, don't mind saving your documents unencrypted on Microsoft's systems, don't worry about being offline, you need collaborate with others online, or just like the convenience of having your documents always online, you can use the 365 version with inferior but probably acceptable performance - in this way everybody is happy.
Veen 5y ago
Surely many of the problems highlighted in this article apply whether it's web or native. Unless all the app's data is generated on device, it needs some way to synchronize with a server, which might either be an "offline-first sync all the data approach" or an "online-only sync a little bit at a time approach".
- lytefm 5y ago
  Exactly, and the boundaries blur even more when you consider that it's possible to build apps that look native to the user with web technology (Electron, Cordova,..) And I'd add than even if all data is generated and stored on the device, syncing capabilities are desirable if the user wants to use his Offline-first app across devices.

An alternative: a native app.

endisneigh 5y ago

native to what?

j1elo 5y ago
The word "native" has diluted in a sea of abstractions and supporting technologies, but in this context I'd read "native app" as removing the browser engine layer (so, not even really native by far, but much closer to the OS and hardware than when writing code on top of the mentioned layer)
- hdjjhhvvhga 5y ago
  Yes. Putting an app in a browser has solved tens of problems and introduced a hundred new ones. At some point you start to wonder if a plain old native app wouldn't work much better that an uncontrollably growing stack of technologies, some ow which designed for something completely different than what we're trying to accomplish.
  - hunterb123 5y ago
    Okay. You still need a client side database with syncing. Which is what this is about. The pure native approach only solves (kind of) the limited storage issues, nothing else. If you nuke your site and only develop about native apps then you'll lose users to competitors because people can try their service without downloading an app. Yeah maybe we shouldn't have shoved an app run-time into a document viewer, but here we are and things run decently well (thanks to v8 and other tech) if you do things right.
    - hdjjhhvvhga 5y ago
      I think you underestimate the number of issues a (purely) native app solves. The fact that many developers don't care about some of them it does not mean they don't exist. One of them is shorter delay, very important in interactive applications. Syncing can be implemented in billion ways, from dedicated solutions to custom ones. Paradoxically, I think Microsoft got it (somewhat) right with Office. You can use a native C++ app, and this is what most people use because of speed and control. However, if you like working online, don't mind saving your documents unencrypted on Microsoft's systems, don't worry about being offline, you need collaborate with others online, or just like the convenience of having your documents always online, you can use the 365 version with inferior but probably acceptable performance - in this way everybody is happy.

Veen 5y ago

Surely many of the problems highlighted in this article apply whether it's web or native. Unless all the app's data is generated on device, it needs some way to synchronize with a server, which might either be an "offline-first sync all the data approach" or an "online-only sync a little bit at a time approach".

lytefm 5y ago
Exactly, and the boundaries blur even more when you consider that it's possible to build apps that look native to the user with web technology (Electron, Cordova,..) And I'd add than even if all data is generated and stored on the device, syncing capabilities are desirable if the user wants to use his Offline-first app across devices.