5 ms·

I really wish we had more control over the scheduling of async tasks. For a javascript example I ran into recently, say I am firing off a fetch for each image

by fyp 7y ago

I really wish we had more control over the scheduling of async tasks. For a javascript example I ran into recently, say I am firing off a fetch for each image that comes into view in a large gallery. If I suddenly scroll down to the 1000th image, a naive implementation might fire off 1000 fetches for all the images we scrolled past. Then you'll be waiting a long time before the images in your current viewport is loaded. Backpressure can save you a little bit here. Say you do the semaphore trick mentioned in the article and only allow a max of say 10 fetches in flight at once. Then if you quickly scroll through, all the subsequent fetches after the initial should fail, including the ones at the viewport you stop at. But since the queue is short, when the images in your current viewport retries it should now succeed. This works but it isn't ideal. Ideally I would be able to just reprioritize the newer fetches to be LIFO instead of FIFO. Or maybe inspect what's currently queued up (and how big the queue is) so I can cancel everything that I don't need. The backpressure solutions might just be a symptom of async tasks not being controllable in any way once started which is why you're forced to commit to it or not from the start even if that might not be the best point in time to make that decision.

crooked-v 7y ago
There's a (overcomplicated) way to cancel pending fetches now: https://developer.mozilla.org/en-US/docs/Web/API/AbortController/abort https://developer.mozilla.org/en-US/docs/Web/API/AbortContro...
girvo 7y ago
So I entirely agree with you. Having some sort of control over the scheduling and execution of async tasks is quite important. And every time I try to implement it in, say, Typescript, I realise that I'm reimplementing Erlang/BEAM. I truly believe BEAM's runtime has a million good ideas in this space that we should be stealing!
- dnautics 7y ago
  or seriously, just use the BEAM. BEAM is coming to the javascript runtime (via WASM)
winrid 7y ago
Instead of starting the fetch when the image comes into view - check every 250ms or so what images are in the viewport.
- zamadatix 7y ago
  If your answer to a JavaScript control flow problem is "fix it with a timer" it's almost never what you want to do. Checking every 250ms just makes things feel delayed for users on fast systems (particularly after a large scroll) and slow for users where 10 images won't load in 250ms while also wasting resources when there is nothing to do. https://news.ycombinator.com/item?id=21932726 https://news.ycombinator.com/item?id=21932726 said exactly what I was typing out on how to handle this general situation without the upcoming API for the exact use case mentioned in this comment https://news.ycombinator.com/item?id=21932328 https://news.ycombinator.com/item?id=21932328
  - winrid 7y ago
    Yeah, no. I would use a queue. Capture the picture-enter-viewport event and then 50ms later (sorry I said 250... probably too long) verify it's still in the viewport like in the case of fast scrolling. Denounce so you don't fire timers for events close together. Works cross browsers, doesn't waste resources, will be smooth.
    - Noumenon72 7y ago
      Did you mean "debounce" instead of "denounce"? Otherwise Google has failed me.
      - winrid 7y ago
        Yeah sorry :)
    - zamadatix 7y ago
      That's not a queue it's just a delayed async call (i.e. if 5,000 calls ask to be called they will all go without queuing in 50ms), what the other comment described is a queue. 50ms is way too short, a user on a 1080p screen would need to scroll at 360 pixels per second to avoid loading every image along the way. Even trying to do that on purpose is hard as hell https://clickspeedtest.com/scroll-test.html https://clickspeedtest.com/scroll-test.html. Guaranteed that every mobile user is going to be loading every image on scroll over 4g as well creating the original back pressure issue now with 3 more frames of lag. "smooth" does not mean "check every 3 frames" it means schedule things in a way they can happen immediately when the browser is ready, not your timer.
DylanDmitri 7y ago
I've found a hybrid model to be generically useful. Keep the first ~10 calls in a FIFO queue, and if that queue is full put additional calls into an LIFO stack that functions as overflow storage. You can even reuse the same data structure and just flip the behavior under load, what's important is having FIFO behavior normally and then LIFO behavior when congestion occurs.
jorblumesea 7y ago
Don't load balancers have some concept of adaptive load balancing? Maybe this is a good idea to port over to the async world.
z3t4 7y ago
Just load all images. No JavaScript! Let the browser handle it. I hate when web sites only display 1-3 pages worth of content and unload/load more when I scroll. The JS code for that uses more resources then pulling everything would. It's a user nightmare, where I cannot use "find" and I can't zoom out, or scroll fast. The browser can easily handle 10,000 DOM elements. There is already optimizations in place in browsers which solve render issues. Beating the browser at it's own job will require a tremendously amount of work. These problem was already solved when computers only had 256MB of memory. And your web site would be blazingly fast today if you did not complicate things.
- fyp 7y ago
  Native lazy loading is an extremely recent feature! https://web.dev/native-lazy-loading/ https://web.dev/native-lazy-loading/ https://caniuse.com/#feat=loading-lazy-attr https://caniuse.com/#feat=loading-lazy-attr So no, browsers don't have these problems solved out of the box. And it seems like what they are implementing will suffer from the exact problem I described here too. I think you might also be thinking of bad implementations of infinite scroll which isn't what I am talking about. Have you never use something like photos.google.com? Scrubbing/scrolling to an arbitrary point in time is honestly a great user experience. Would you rather wait hours/days for a webpage to load all the past photos images you've ever taken? Or have to deal with pagination and click through hundreds of pages to find what you want?
dr-detroit 7y ago
Isn't infinite scroll lazy loading ubiquitous in 2020? Without searching Im going to guess theres 500000 JS libraries to do this work and at least 14 good ones.

by fyp 7y ago

crooked-v 7y ago

There's a (overcomplicated) way to cancel pending fetches now: https://developer.mozilla.org/en-US/docs/Web/API/AbortController/abort https://developer.mozilla.org/en-US/docs/Web/API/AbortContro...

girvo 7y ago

So I entirely agree with you. Having some sort of control over the scheduling and execution of async tasks is quite important. And every time I try to implement it in, say, Typescript, I realise that I'm reimplementing Erlang/BEAM. I truly believe BEAM's runtime has a million good ideas in this space that we should be stealing!

dnautics 7y ago
or seriously, just use the BEAM. BEAM is coming to the javascript runtime (via WASM)

winrid 7y ago

Instead of starting the fetch when the image comes into view - check every 250ms or so what images are in the viewport.

zamadatix 7y ago
If your answer to a JavaScript control flow problem is "fix it with a timer" it's almost never what you want to do. Checking every 250ms just makes things feel delayed for users on fast systems (particularly after a large scroll) and slow for users where 10 images won't load in 250ms while also wasting resources when there is nothing to do. https://news.ycombinator.com/item?id=21932726 https://news.ycombinator.com/item?id=21932726 said exactly what I was typing out on how to handle this general situation without the upcoming API for the exact use case mentioned in this comment https://news.ycombinator.com/item?id=21932328 https://news.ycombinator.com/item?id=21932328
- winrid 7y ago
  Yeah, no. I would use a queue. Capture the picture-enter-viewport event and then 50ms later (sorry I said 250... probably too long) verify it's still in the viewport like in the case of fast scrolling. Denounce so you don't fire timers for events close together. Works cross browsers, doesn't waste resources, will be smooth.
  - Noumenon72 7y ago
    Did you mean "debounce" instead of "denounce"? Otherwise Google has failed me.
    - winrid 7y ago
      Yeah sorry :)
  - zamadatix 7y ago
    That's not a queue it's just a delayed async call (i.e. if 5,000 calls ask to be called they will all go without queuing in 50ms), what the other comment described is a queue. 50ms is way too short, a user on a 1080p screen would need to scroll at 360 pixels per second to avoid loading every image along the way. Even trying to do that on purpose is hard as hell https://clickspeedtest.com/scroll-test.html https://clickspeedtest.com/scroll-test.html. Guaranteed that every mobile user is going to be loading every image on scroll over 4g as well creating the original back pressure issue now with 3 more frames of lag. "smooth" does not mean "check every 3 frames" it means schedule things in a way they can happen immediately when the browser is ready, not your timer.

DylanDmitri 7y ago

I've found a hybrid model to be generically useful. Keep the first ~10 calls in a FIFO queue, and if that queue is full put additional calls into an LIFO stack that functions as overflow storage. You can even reuse the same data structure and just flip the behavior under load, what's important is having FIFO behavior normally and then LIFO behavior when congestion occurs.

jorblumesea 7y ago

Don't load balancers have some concept of adaptive load balancing? Maybe this is a good idea to port over to the async world.

z3t4 7y ago

Just load all images. No JavaScript! Let the browser handle it. I hate when web sites only display 1-3 pages worth of content and unload/load more when I scroll. The JS code for that uses more resources then pulling everything would. It's a user nightmare, where I cannot use "find" and I can't zoom out, or scroll fast. The browser can easily handle 10,000 DOM elements. There is already optimizations in place in browsers which solve render issues. Beating the browser at it's own job will require a tremendously amount of work. These problem was already solved when computers only had 256MB of memory. And your web site would be blazingly fast today if you did not complicate things.

fyp 7y ago
Native lazy loading is an extremely recent feature! https://web.dev/native-lazy-loading/ https://web.dev/native-lazy-loading/ https://caniuse.com/#feat=loading-lazy-attr https://caniuse.com/#feat=loading-lazy-attr So no, browsers don't have these problems solved out of the box. And it seems like what they are implementing will suffer from the exact problem I described here too. I think you might also be thinking of bad implementations of infinite scroll which isn't what I am talking about. Have you never use something like photos.google.com? Scrubbing/scrolling to an arbitrary point in time is honestly a great user experience. Would you rather wait hours/days for a webpage to load all the past photos images you've ever taken? Or have to deal with pagination and click through hundreds of pages to find what you want?

dr-detroit 7y ago

Isn't infinite scroll lazy loading ubiquitous in 2020? Without searching Im going to guess theres 500000 JS libraries to do this work and at least 14 good ones.