3 ms·

network latency still fails to catch up to human awareness' time resolution. client-side logic, done right is much improved over a server-side solution.

ArkyBeagle 11y ago
Which network and which latency? My local network runs audio way below the Haas limit - I can record over the network without incurring any latency penalty.
- jordache 11y ago
  are you serious? Are you saying the delay between a full req/res round trip + page redraw is indistinguishable from dynamically updating page elements? If you're drugged up on benadryl, then I'd say yes,
  - ArkyBeagle 11y ago
    English much? I said audio. I provided this as a counterexample to the stated thesis of your post. There exist things that can be done over a network such that latency is not an issue. I am obviously not pulling data over a cross-continental link. FWIW, the protocols I write at work can do a full data pull - a couple thousand elements and growing - in under a half second end to end. I don't know of any HTML/Web based protocols that can even get close to that over localhost. So yeah - we know the Web is an utter pig. My point is that it probably doesn't have to be.
    - jordache 11y ago
      Reading comprehension much? The article was specifically about web page payload size. My comment was comparing UX of dynamic client-side logic vs full round trips. You must replied to the wrong comment, I would hope.
- detaro 11y ago
  Comparing local-network performance with "random" cross-internet traffic IMHO isn't very useful, because there is a wide range for internet latency. My wired desktop gets DNS responses from 8.8.8.8 nearly as if it were in my network, in way under 10 ms, ping responses in 2 ms or so. Accessing websites hosted in e.g. Korea takes >100 ms. Add a congested wireless connection somewhere (WLAN or mobile network) and you can add another few hundred ms. And neither cross-continent nor congested wireless latency is going to go away.
  - ArkyBeagle 11y ago
    Perhaps I should have been more explicit - comparing local audio traffic to local web traffic, there's a heck of a lot of difference. That would be the stacks.

ArkyBeagle 11y ago

Which network and which latency? My local network runs audio way below the Haas limit - I can record over the network without incurring any latency penalty.

jordache 11y ago
are you serious? Are you saying the delay between a full req/res round trip + page redraw is indistinguishable from dynamically updating page elements? If you're drugged up on benadryl, then I'd say yes,
- ArkyBeagle 11y ago
  English much? I said audio. I provided this as a counterexample to the stated thesis of your post. There exist things that can be done over a network such that latency is not an issue. I am obviously not pulling data over a cross-continental link. FWIW, the protocols I write at work can do a full data pull - a couple thousand elements and growing - in under a half second end to end. I don't know of any HTML/Web based protocols that can even get close to that over localhost. So yeah - we know the Web is an utter pig. My point is that it probably doesn't have to be.
  - jordache 11y ago
    Reading comprehension much? The article was specifically about web page payload size. My comment was comparing UX of dynamic client-side logic vs full round trips. You must replied to the wrong comment, I would hope.
detaro 11y ago
Comparing local-network performance with "random" cross-internet traffic IMHO isn't very useful, because there is a wide range for internet latency. My wired desktop gets DNS responses from 8.8.8.8 nearly as if it were in my network, in way under 10 ms, ping responses in 2 ms or so. Accessing websites hosted in e.g. Korea takes >100 ms. Add a congested wireless connection somewhere (WLAN or mobile network) and you can add another few hundred ms. And neither cross-continent nor congested wireless latency is going to go away.
- ArkyBeagle 11y ago
  Perhaps I should have been more explicit - comparing local audio traffic to local web traffic, there's a heck of a lot of difference. That would be the stacks.