As someone who has done what I will call "corporate web dev" for a long time, it's almost never the actual site or web app that is abusing your resources. It's all the junk 3rd-party scripts that the business and marketing people force onto it.
These scripts are intended to be "low code" solutions. Even if the developers working at those places mean well, nobody reads their docs least of which the marketing goons with unfettered access via a CSP nonce copy-pasting whatever example <script> tags they think they need to inject to make the thing go.
If you ever want a laugh and have tons of free time you should find one of those sites loaded with these kinds of scripts that an ad blocker would normally get rid of, read the docs for how those scripts were supposed to be used, and bask in the insane stupidity and cargo cult nonsense causing duplicate events and many redundant http calls and websockets... and then turn your ad blocker back on.
You may then ask yourself sensible questions such as: "doesn't all this royally fuck up their analytics data?" and "does some poor soul making reports from that mess ever clean it up?". The answer is yes it does, and no they don't. They instead will try to play the blame game and claim it's the underlying site or web app causing the issues until they find another job. There's a lot of churn in that space.
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.
Seems like it has been removed though based on jayflux's comment.
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.
Timer precision from performance.now and other sources is reduced to 1ms (r226495)
https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-...
The precision of setTimeout has never been high, it kind-of maps to the OS scheduler and the OS scheduler often enforce their own minimum timeouts (Windows has defaulted to 15.625 ms resolution for a very long time, and the newer high resolution timers max out at 1ms across most operating systems)
Thanks for including that example!
[0] https://github.com/catapart/record-setter?tab=readme-ov-file...
"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."
https://developer.mozilla.org/en-US/docs/Glossary/blink_elem...
> And the beast shall come forth surrounded by a roiling cloud of vengeance. The house of the unbelievers shall be razed and they shall be scorched to the earth. Their tags shall blink until the end of days. — from The Book of Mozilla, 12:10
“Do this {} at least Xms from now”, right?
Any busy runtime (e.g. one with lots of parallel tasks, plus anything running less than optimally) will have a delay.
Imagine this code:
let value = 0;
(function tick () {
value += 1;
console.log(value);
setTimeout(tick, 1);
})();
So it is with JS; I kinda figured EVERYTHING would need to be heavily throttled in a browser in order to respect the device running that browser.
Is this still the case? Even with this change? https://chromestatus.com/feature/4889002157015040
Edit: Here's the MDN bit on that, I was correct:
https://developer.mozilla.org/en-US/docs/Web/API/Window/setT...
> browsers will enforce a minimum timeout of 4 milliseconds once a nested call to setTimeout has been scheduled 5 times.
And the link from there to the spec about that:
https://html.spec.whatwg.org/multipage/timers-and-user-promp...
> If nesting level is greater than 5, and timeout is less than 4, then set timeout to 4.
Previously the first 5 would take 1ms, and then the rest would take 4ms. After that change the first 5 take 0ms and the rest take 4ms.
Technically it is a browser. Unless I am making a serious logic flaw here, it should be applicable.
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.