4 ms·

Technical reasons are honestly overblown - it all boils down to one, business, reason - control. When you do serverside stuff you control everything. What user

Technical reasons are honestly overblown - it all boils down to one, business, reason - control. When you do serverside stuff you control everything. What users can do, and cannot do. This lets you both reduce support costs as it is easier to resolve issues even by ad-hoc db query, and more importantly - it lets you retroactively lock more and more useful features behind paywall. This is basically The DRM for your software with extra bonus - you don't even have to compete with previous version of your own software! i want my local programs back, but without regulatory change it will never happen.

hobs 1y ago
Yep at every company I have ever worked at the question is not only how to assert control, but how to maintain it for the long term. Even if the company isn't exploiting you today, they want the option for later.
gwbas1c 1y ago
> Technical reasons are honestly overblown Having built a sync product, it is dramatically simpler (from a technical standpoint) to require that clients are connected, send operations immediately to central location, and then succeed / fail there. Once things like offline sync are part of the picture, there's a whole set of infrequent corner cases that come in that are also very difficult to explain to non-technical people. These are silly things like: If there's a network error after I sent the last byte to a server, what do I do? You (the client that made the request) don't know if the server actually processed the request. If you're completely reliant on the server for your state, this problem (cough) "doesn't exist", because when the user refreshes, they either see their change or they don't. But, if you have offline sync, you need to either have the server tolerate a duplicate submission, or you need some kind of way for the client to figure out that the server processed the submission.
- Xelbair 1y ago
  but it is nothing that cannot be solved - if it was more profitable we would all be doing it.
  - gwbas1c 1y ago
    Oh, it's very solvable. (As I pointed out.) The bigger issue is naivety. A lot of these corner cases mean that it's unlikely someone can just put together a useful prototype in a weekend or two. > if it was more profitable we would all be doing it. More like, if there was more demand we would all be doing it. Most of us have reliable internet connections and don't go out of service often enough to really care about this kind of thing.
JustExAWS 1y ago
Well, I have three devices I would like to work with depending on what I am holding in my hand - my phone, tablet and computer. I want all of my devices to be in sync. Right now, I can throw my phone in the ocean, go to the Apple Store, sign in and my new phone looks and acts like my old phone with all of my data available, my apps and my icons being in the same place. My wife and I can share calendar events, spreadsheets, photo libraries etc. That’s not to mention work.

hobs 1y ago

Yep at every company I have ever worked at the question is not only how to assert control, but how to maintain it for the long term. Even if the company isn't exploiting you today, they want the option for later.

gwbas1c 1y ago

> Technical reasons are honestly overblown Having built a sync product, it is dramatically simpler (from a technical standpoint) to require that clients are connected, send operations immediately to central location, and then succeed / fail there. Once things like offline sync are part of the picture, there's a whole set of infrequent corner cases that come in that are also very difficult to explain to non-technical people. These are silly things like: If there's a network error after I sent the last byte to a server, what do I do? You (the client that made the request) don't know if the server actually processed the request. If you're completely reliant on the server for your state, this problem (cough) "doesn't exist", because when the user refreshes, they either see their change or they don't. But, if you have offline sync, you need to either have the server tolerate a duplicate submission, or you need some kind of way for the client to figure out that the server processed the submission.

Xelbair 1y ago
but it is nothing that cannot be solved - if it was more profitable we would all be doing it.
- gwbas1c 1y ago
  Oh, it's very solvable. (As I pointed out.) The bigger issue is naivety. A lot of these corner cases mean that it's unlikely someone can just put together a useful prototype in a weekend or two. > if it was more profitable we would all be doing it. More like, if there was more demand we would all be doing it. Most of us have reliable internet connections and don't go out of service often enough to really care about this kind of thing.

JustExAWS 1y ago

Well, I have three devices I would like to work with depending on what I am holding in my hand - my phone, tablet and computer. I want all of my devices to be in sync. Right now, I can throw my phone in the ocean, go to the Apple Store, sign in and my new phone looks and acts like my old phone with all of my data available, my apps and my icons being in the same place. My wife and I can share calendar events, spreadsheets, photo libraries etc. That’s not to mention work.