Is It Useful To Make The Drag Of Mousedragging Happening Inside RequestAnimationFrame?

I have a dragging library which moves the element on every mousemove. As we all know, mousemove fires quite often and thus forces the browser into repaints. This could be solved, b

Solution 1:

Depends on the browser and the use case.

It is now asked by the specs that browsers do threshold themselves UI events (among which the mouse events).

Implementations are encouraged to determine the optimal frequency rate to balance responsiveness with performance.

Chrome and Firefox do this, firing these events only at screen refresh rate, just before requestAniamtionFrame callbacks fire.
So in these browsers, you won't win anything by doing so, but you won't lose much either.

Safari still fires as many such events as the device emits, so in this browser you'll win by maintaining your own threshold.

(Note that if you wish to unleash this threshold, you'll need to use pointerevents instead.)

---

Now, this is useful to avoid uselessly calculating things that will get discarded by next calls before it can get painted.
The painting will always be throttled to the refresh rate of your screen (just after the requestAnimationFrame callbacks fire).
So it's up to you to determine if you wish to apply that threshold or not.
For instance it can make sense to update a list of points as fast as possible, but to wait the requestAnimationFrame callback to actually make DOM changes or draw anything.

From the little you said about your case, it seems though that you may indeed win by waiting for requestAnimationFrame callbacks, only because you may be modifying the box model of your CSSOM.