Hacker News Reader

> I wonder how much javascript code uses setTimeout(x,0) to push code to the end of the run loop.

Probably heaps, but why would that cause the system-wide timer to run more frequently? Even if it does need to it should only be temporary.

View on HN

Any timer is constrained to the resolution set by the system timer. To go lower one would require something akin to a spin-loop, which defeats any gain by keeping the resolution high.

setTimeout(,0) is a special case. It means "make this function be ran after the current call stack clears". That requires neither a timer nor a spin loop.

If browsers did that they would break the Web. They must clamp to some low delay (4 ms, I believe) or else some pages will lock up.

See https://bugzilla.mozilla.org/show_bug.cgi?id=123273

Right, but that precedent was only set by incorrect implementations existing in the first place. Using setTimeout(,0) recursively in lieu of (a then unavailable) requestAnimationFrame or a non-zero timeout period is in my mind equivalent to while(true){}/infinite tail recursion.

And yes, in the HTML5 spec (years later), it was standardized to a 4ms clamp, also because of the incorrect implementations prior.

Reply on news.ycombinator.com