I've just found out about window.requestIdleCallback and I am wondering on the difference with just a plain promise.
As far as I know JS is already good at queuing promises, so I do not see any benefit unless requestIdleCallback uses a different queue with lower priority. In that case I would assume it is great because I would like having a way to make clear which code has lower priority than rendering.
window.requestIdleCallback simply runs the function during the browser idle periods to avoid impacting animations and input responses etc.
Promises are just a way of using asynchronous code. That code may be run while the browser is not idle (if the promise is not pending), and could possibly impact latency critical events.
Therefore, promises may or may not run during the browser idle period, but the requestIdleCallback will always run in the idle period (assuming the timeout isn't exceeded).
Please note, these 2 concepts are not interchangeable. Yes, you can run asynchronous "promise" code within the requestIdleCallback, but the callback should not be used to replace the functionality of a promise. That is, you shouldn't replace the use of promises with the callback, but use them together if appropriate.
Here's some info about window.requestIdleCallback:
https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
And Promises here:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise