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.
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.
“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.
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)
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.
Thanks for including that example!
[0] https://github.com/catapart/record-setter?tab=readme-ov-file...
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.
Technically it is a browser. Unless I am making a serious logic flaw here, it should be applicable.
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?
BinaryIgor•4mo ago
"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."
AgentME•4mo ago
raw_anon_1111•4mo ago
https://developer.mozilla.org/en-US/docs/Glossary/blink_elem...
toast0•4mo ago
> 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