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. Show 2 replies

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.

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.

Show 3 replies

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...

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."

Show 1 reply

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?

Show 4 replies

> 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

Show 2 replies

OK, but this doesn't really answer the question. If setTimeout() could be abused by creating a busy loop, why couldn't the same be done with postTask()?

Or in other words, why is the "protect web devs from themselves" camp ok with only "securing" one API but not the other?

As for "put up interventions to nudge devs to use the right APIs": What ever happened to "paving the cowpaths"? Wasn't that the big idea in WHATWG circles originally? So if web devs are familiar with setTimeout() and tend to use it for all kinds of things, why not improve that API instead of trying to coax devs into using a new one?

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.

This was news to me but incredibly interesting: https://developer.mozilla.org/en-US/docs/Web/API/Scheduler/p...

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