4 ms·

For many people wireless connectivity is spotty at best; particularly rural USA, most of Canada, and much of the non-western world. Whereas home internet conne

For many people wireless connectivity is spotty at best; particularly rural USA, most of Canada, and much of the non-western world. Whereas home internet connections tend to be fairly reliable. Anecdotally, I don't rely on web apps because the terrible network reliability that I have means that they are frustratingly slow and frequently outright break. Native mobile apps work just fine.

brundolf 5y ago
Properly-written PWAs can keep code and data locally cached to avoid this problem. Of course most companies just don't bother implementing that stuff
- dleslie 5y ago
  If most of the business logic is on a server then caching doesn't help; there's too many misses. Besides, major draws for building web apps includes control of user data and keeping business logic behind an API.
  - brundolf 5y ago
    There's nothing technical that stops you from putting business logic in the web client any more than on native (except I guess working with local files, but not many mobile apps do that these days anyway). I'm just saying, if the key benefit is not having to download the app every time you open it, and instead only downloading the actual data as needed (to save on bandwidth), PWAs can serve that usecase (if they're designed to).
    - adrianmonk 5y ago
      I think this is technically viable, but I wonder if a lot of projects fail (from a performance perspective) because teams don't realize the limitations of mobile networks early enough. So they develop everything on wifi, and it seems OK, and they make certain design choices. Then after they launch, performance is terrible when people try to use it on cell networks. By then it's too late to fix performance because they'd have to re-architect the whole thing. The lesson they could take away from it -- the one that would be most accurate -- is, "We should have designed our mobile web client differently." But the subtlety is lost and the message everyone learns is more like, "Last time, when we did a mobile web client approach, it was a disaster. Let's never do that again. From now on, it's native apps."
adrianmonk 5y ago
> terrible network And it's worse than just reliability. It's also performance. TCP just does not work well over wireless networks. Its congestion control is designed to allow multiple TCP streams to coexist on a network that has steady bandwidth. It works fine if the network layer is basically stable and the problem is sharing it. On mobile networks, the available bandwidth fluctuates wildly over a short time period. When the bandwidth drops, TCP backs off exponentially, and when the bandwidth returns, TCP does not ramp back up quickly enough. So it ends up sitting around doing almost nothing when there's bandwidth available. So even when the network is working, native apps typically perform better because they lend themselves to separating network activity from user interaction. With the web, unless you do a single page web app, navigating to different screens and views of things tends to be a page load, which is just too slow too often.

brundolf 5y ago

Properly-written PWAs can keep code and data locally cached to avoid this problem. Of course most companies just don't bother implementing that stuff

dleslie 5y ago
If most of the business logic is on a server then caching doesn't help; there's too many misses. Besides, major draws for building web apps includes control of user data and keeping business logic behind an API.
- brundolf 5y ago
  There's nothing technical that stops you from putting business logic in the web client any more than on native (except I guess working with local files, but not many mobile apps do that these days anyway). I'm just saying, if the key benefit is not having to download the app every time you open it, and instead only downloading the actual data as needed (to save on bandwidth), PWAs can serve that usecase (if they're designed to).
  - adrianmonk 5y ago
    I think this is technically viable, but I wonder if a lot of projects fail (from a performance perspective) because teams don't realize the limitations of mobile networks early enough. So they develop everything on wifi, and it seems OK, and they make certain design choices. Then after they launch, performance is terrible when people try to use it on cell networks. By then it's too late to fix performance because they'd have to re-architect the whole thing. The lesson they could take away from it -- the one that would be most accurate -- is, "We should have designed our mobile web client differently." But the subtlety is lost and the message everyone learns is more like, "Last time, when we did a mobile web client approach, it was a disaster. Let's never do that again. From now on, it's native apps."

adrianmonk 5y ago

> terrible network And it's worse than just reliability. It's also performance. TCP just does not work well over wireless networks. Its congestion control is designed to allow multiple TCP streams to coexist on a network that has steady bandwidth. It works fine if the network layer is basically stable and the problem is sharing it. On mobile networks, the available bandwidth fluctuates wildly over a short time period. When the bandwidth drops, TCP backs off exponentially, and when the bandwidth returns, TCP does not ramp back up quickly enough. So it ends up sitting around doing almost nothing when there's bandwidth available. So even when the network is working, native apps typically perform better because they lend themselves to separating network activity from user interaction. With the web, unless you do a single page web app, navigating to different screens and views of things tends to be a page load, which is just too slow too often.