HN Reader

I remember reading that high precision timers can be used for browser fingerprinting and/or for timing attacks, but I didn't anything specifically about setTimeout()/setInterval() after searching a bit.

Also--loosening the accuracy of timers allows the system to optimize CPU power states and save battery. Again, not sure if that's related here.

Maybe someone else here can add more detail.

Because browser developers still have major incentive to care about not misusing the resources (cpu/battery) of browser users, and website developers very clearly do not.

I was aware of that for browsers; is this also true for Electron?

Have I not always heard that timeout-based callbacks always run at or after the timeout, but never before?

“Do this {} at least Xms from now”, right?

> Even if you’ve been doing JavaScript for a while, you might be surprised to learn that setTimeout(0) is not really setTimeout(0). Instead, it could run 4 milliseconds later:

Is this still the case? Even with this change? https://chromestatus.com/feature/4889002157015040

As someone who wrote an entire indexedDB wrapper library just to understand the "micro task" issues that are referenced in this blog post, and THEN dedicated a couple hundred words of my readme to explaining this footgun[0], I am so glad to hear about `scheduler.postTask`. That's new information to me!

Thanks for including that example!

[0] https://github.com/catapart/record-setter?tab=readme-ov-file...

I asked about this a few years ago on SO and there is some good info: https://stackoverflow.com/q/61338780/265521

E.g. Chrome has this comment:

  // Chromium uses a minimum timer interval of 4ms. We'd like to go
  // lower; however, there are poorly coded websites out there which do
  // create CPU-spinning loops.  Using 4ms prevents the CPU from
  // spinning too busily and provides a balance between CPU spinning and
  // the smallest possible interval timer.

At the time at least the 4ms only kicks in after 5 levels of nesting, as mentioned in the article, but there was still a 1ms limit before that.

Seems like it has been removed though based on jayflux's comment.

The story of web development:

"For the time being, I’ll just do what most web devs do: choose whatever API accomplishes my goals today, and hope that browsers don’t change too much in the future."

Background javascript processes can really seem to add up across a lot of browser tabs firing up to stay "smart" or "current" like they're the only tab in existence in their user's life.

I'm not sure if many people struggle with browser tabs gone wild. Limiting Javascript can have varying degrees of success since it's relative to how the page/site/app is built to begin with.