3 ms·

Hopefully at some point actual click latency will be fixed in general after some dark decades. Still incredible that a gameboy or an 80's computer with a CRT f

Hopefully at some point actual click latency will be fixed in general after some dark decades. Still incredible that a gameboy or an 80's computer with a CRT feels more responsive than most devices these days. Bring back tactility. I'm convinced the choppiness and weird waits are actually psychologically stressing us out. That's why good keyboards + old low latency OS'es or typewriters are so soothing to use.

coldblues 3y ago
Latency will always be an issue as long as developers use web technologies. Nothing beats native.
CharlesW 3y ago
> Hopefully at some point actual click latency will be fixed in general after some dark decades. Meaning, the 300ms delay (if the site developer does no optimization) with mobile browsers?
- tentacleuno 3y ago
  Context for the 300ms delay: https://developer.chrome.com/blog/300ms-tap-delay-gone-away/ https://developer.chrome.com/blog/300ms-tap-delay-gone-away/
  - CharlesW 3y ago
    Some other ways to mitigate: https://www.sitepoint.com/5-ways-prevent-300ms-click-delay-mobile-devices/ https://www.sitepoint.com/5-ways-prevent-300ms-click-delay-m...
olliej 3y ago
What is the latency being referred to here? I don’t see noticeable lag on pressing/tapping buttons or other ui components in day to day browsing, even on my quite old iPhone. There are obviously ways to make delays in web content anyway (user action->synchronous network request being the canonical one), but assuming there’s nothing silly like that lag isn’t an issue I’ve noticed. Actual execution latency is something I worked on for many years in JSC, and so there are a lot of engine optimizations to reduce that latency as much as possible (the interpreter itself, the interpreter performance, byte code caches, hilarious amounts of lazy parsing and source skipping, etc) so even the first time you have a ui element trigger code there shouldn’t be any significant delay. Obviously if a developer makes poor choices there’s only so much you can do, but by and large there aren’t that many bad things a web developer can do that a native dev can’t also do (and devs in both environments frequently do :-/).

coldblues 3y ago

Latency will always be an issue as long as developers use web technologies. Nothing beats native.

CharlesW 3y ago

> Hopefully at some point actual click latency will be fixed in general after some dark decades. Meaning, the 300ms delay (if the site developer does no optimization) with mobile browsers?

tentacleuno 3y ago
Context for the 300ms delay: https://developer.chrome.com/blog/300ms-tap-delay-gone-away/ https://developer.chrome.com/blog/300ms-tap-delay-gone-away/
- CharlesW 3y ago
  Some other ways to mitigate: https://www.sitepoint.com/5-ways-prevent-300ms-click-delay-mobile-devices/ https://www.sitepoint.com/5-ways-prevent-300ms-click-delay-m...

olliej 3y ago

What is the latency being referred to here? I don’t see noticeable lag on pressing/tapping buttons or other ui components in day to day browsing, even on my quite old iPhone. There are obviously ways to make delays in web content anyway (user action->synchronous network request being the canonical one), but assuming there’s nothing silly like that lag isn’t an issue I’ve noticed. Actual execution latency is something I worked on for many years in JSC, and so there are a lot of engine optimizations to reduce that latency as much as possible (the interpreter itself, the interpreter performance, byte code caches, hilarious amounts of lazy parsing and source skipping, etc) so even the first time you have a ui element trigger code there shouldn’t be any significant delay. Obviously if a developer makes poor choices there’s only so much you can do, but by and large there aren’t that many bad things a web developer can do that a native dev can’t also do (and devs in both environments frequently do :-/).