5 ms·

What's the use case? What is "your site" doing that it would need all this computing power?

Kiro 4y ago
What kind of question is that? Games or applications like Figma obviously require more computing power than a static homepage.
- postalrat 4y ago
  Figma isn't my site.
- remram 4y ago
  Do they? To do what when the computer is idle? Those are interactive applications, there's not that much work for them to do when you're not interacting with them.
  - Kiro 4y ago
    It's not about the computer being idle. It's about waiting for the main thread to be unblocked before doing stuff you would want to do anyway, but now you can schedule it for later to give priority to more urgent tasks. A very common optimization technique in all sorts of software and I don't see why it wouldn't be valid for a web application. Go read https://developer.mozilla.org/en-US/docs/Web/API/Background_Tasks_API https://developer.mozilla.org/en-US/docs/Web/API/Background_... for a better explanation.
    - remram 4y ago
      You still haven't answered the question. Your link has no example of use cases, though it has warnings about what not to do.
      - collaborative 4y ago
        Can't reply above. So it's "low-priority" async?
      - Kiro 4y ago
        Example: In a map application you give priority to rendering the visible map tiles while deferring preloading the surrounding non-visible tiles until the CPU is free. So basically it only renders tiles outside the viewport in a cache if the CPU is not already busy rendering what you're currently looking at. Any sort of thing that is not urgent and high priority, and where it's no big deal if it's not executed immediately will benefit from being run in requestIdleCallback.
  - jasonjmcghee 4y ago
    If you do too much work at once on the main thread, the application will visibly freeze. Say you need to call a few rest apis that trigger changes to the DOM. If the user is actively interacting with your application, doing an operation like this, say every 5 seconds, could cause momentary lag that feels bad. What if you could wait to do the update until the main thread is free?
    - collaborative 4y ago
      Question.. is this using multiple threads? If it isn't, how is this different than async operations?
      - remram 4y ago
        It is async, the operation is delayed until the processor has nothing important to do.
    - remram 4y ago
      Making changes to the DOM seconds later is the part I don't get. Either it's part of interaction and therefore it's urgent, or it's... what?
      - sheusndudn 4y ago
      - leipert 4y ago
        At work we have these time strings, e.g. “2 min ago”. We show a tooltip when the user hovers over them. We can defer the initialization of the “show-tooltip” logic because surely those tooltips are less important than other things on the page. Same with links to user profiles.
  - sheusndudn 4y ago
  - dewey 4y ago
    They are collaborative applications, if you come back to your screen it could be desireable to have all the changes your coworkers did in the mean time reflected.
eyelidlessness 4y ago
It allows you to temporarily unblock the main thread/renderer before performing a potentially expensive computation. I’ve used this technique (with plain requestIdleCallback) to display incremental UI feedback as a chain of computations progresses. This is in an application I inherited/maintain, with some existing performance problems. I intend to make more substantive performance improvements, but this stopgap measure significantly improves perceived performance, eg by immediately showing the effect of a direct interaction such as a checkbox state change even if the triggered computations may take ~500ms. The downside is it potentially introduces “jank”, where incremental changes render temporarily, and computation time is somewhat slower overall. In my experience/opinion, the tradeoff is worth it around 100-200ms depending on what’s being unblocked.
dheera 4y ago
Mine bitcoin on users' computers for you when they are idle?

Kiro 4y ago

What kind of question is that? Games or applications like Figma obviously require more computing power than a static homepage.

postalrat 4y ago
Figma isn't my site.
remram 4y ago
Do they? To do what when the computer is idle? Those are interactive applications, there's not that much work for them to do when you're not interacting with them.
- Kiro 4y ago
  It's not about the computer being idle. It's about waiting for the main thread to be unblocked before doing stuff you would want to do anyway, but now you can schedule it for later to give priority to more urgent tasks. A very common optimization technique in all sorts of software and I don't see why it wouldn't be valid for a web application. Go read https://developer.mozilla.org/en-US/docs/Web/API/Background_Tasks_API https://developer.mozilla.org/en-US/docs/Web/API/Background_... for a better explanation.
  - remram 4y ago
    You still haven't answered the question. Your link has no example of use cases, though it has warnings about what not to do.
    - collaborative 4y ago
      Can't reply above. So it's "low-priority" async?
    - Kiro 4y ago
      Example: In a map application you give priority to rendering the visible map tiles while deferring preloading the surrounding non-visible tiles until the CPU is free. So basically it only renders tiles outside the viewport in a cache if the CPU is not already busy rendering what you're currently looking at. Any sort of thing that is not urgent and high priority, and where it's no big deal if it's not executed immediately will benefit from being run in requestIdleCallback.
- jasonjmcghee 4y ago
  If you do too much work at once on the main thread, the application will visibly freeze. Say you need to call a few rest apis that trigger changes to the DOM. If the user is actively interacting with your application, doing an operation like this, say every 5 seconds, could cause momentary lag that feels bad. What if you could wait to do the update until the main thread is free?
  - collaborative 4y ago
    Question.. is this using multiple threads? If it isn't, how is this different than async operations?
    - remram 4y ago
      It is async, the operation is delayed until the processor has nothing important to do.
  - remram 4y ago
    Making changes to the DOM seconds later is the part I don't get. Either it's part of interaction and therefore it's urgent, or it's... what?
    - sheusndudn 4y ago
    - leipert 4y ago
      At work we have these time strings, e.g. “2 min ago”. We show a tooltip when the user hovers over them. We can defer the initialization of the “show-tooltip” logic because surely those tooltips are less important than other things on the page. Same with links to user profiles.
- sheusndudn 4y ago
- dewey 4y ago
  They are collaborative applications, if you come back to your screen it could be desireable to have all the changes your coworkers did in the mean time reflected.

eyelidlessness 4y ago

It allows you to temporarily unblock the main thread/renderer before performing a potentially expensive computation. I’ve used this technique (with plain requestIdleCallback) to display incremental UI feedback as a chain of computations progresses. This is in an application I inherited/maintain, with some existing performance problems. I intend to make more substantive performance improvements, but this stopgap measure significantly improves perceived performance, eg by immediately showing the effect of a direct interaction such as a checkbox state change even if the triggered computations may take ~500ms. The downside is it potentially introduces “jank”, where incremental changes render temporarily, and computation time is somewhat slower overall. In my experience/opinion, the tradeoff is worth it around 100-200ms depending on what’s being unblocked.

dheera 4y ago

Mine bitcoin on users' computers for you when they are idle?