I actually like having software and hardware that can be idle. I find it quite peculiar that some app/window/page I'm explicitly not interacting with should be doing work because I'm not interacting with it.

What I’d really like to see on this page is more descriptive text. Mainly a description of what’s actually being done by the library. But also a section on when I should use idle-task over Partytown - https://partytown.builder.io/

Couldn’t this have negative impact on user battery life depending on the weight of the JS or number of open tabs with sites using it? Seems like it might be antagonistic to host OS efforts to to coalesce work and perform it while the CPU is already awake to reduce the number of wakeups and save power, since it specifically waits for browser idle.

One of the extensions that suspends idle tabs can protect me from this?

Or... use a web worker

I have an idea: why not speed up your site by NOT running js at all?

What's the use case? What is "your site" doing that it would need all this computing power?

It seems like people are reading this like "add this thing to always busy wait so your site goes faster and drains battery" when in reality it's just saying "schedule low priority tasks to happen at next idle"

As other comments have pointed out, this behavior is enabled by `requestIdleCallback`.

MDN has a good example and looks like this is not supported by Safari -

https://developer.mozilla.org/en-US/docs/Web/API/Background_...

This comment thread is a serious mess with all sorts of bad faith takes that have nothing to do with the library. Go read https://developer.mozilla.org/en-US/docs/Web/API/Window/requ... and https://developer.mozilla.org/en-US/docs/Web/API/Background_...

This is not used for malicious CPU hijacking or whatever. It's a way to schedule low-priority JS tasks for later and give priority to more important things. It's a very useful API for when optimizing games or complex web applications.

While unrelated to this, I would like browsers to suspend background tabs and maybe even compress their data and unload information that can be restored later (for example, unload images from memory, drop JS bytecode and JIT caches). Majority of websites have no need to do anything when I am not watching them.

Of course there are cases when you need some background activity, for example if you are listening to music or running a program. As I understand, it is extremely difficult do distuinguish between tabs doing useful work and not doing. I would be fine with a manual switch to allow site run in background.

This is a neat idea, but it's pretty rare that I find myself with a compute-heavy JS task (slow enough to visibly impact performance) that can be neatly split off into an asynchronous process like this (i.e. isn't just part of my UI framework's main rendering process). And the couple times where that has happened, I preferred to spin up a background worker and get true parallelism. The message passing comes with some overhead, but that got swallowed by the fact that it was a heavy task

This looks well-designed and I'm sure somebody has a usecase for it, but I'm not sure I've ever had one

The main issue with 3rd party scripts is that each one wants to be the first to run. And they are usually the ones that take up the most CPU time and bandwidth.

For some scripts "facade" solution might work even better than running them on idle. Consider a "chat plugin", that usually pops up each time you visit. If we'd replace chat script with simple dummy button, that loads actual script when user really needs to talk to website support - visitor wins as they are not bothered by popups and site loads faster.

Any ideas how to apply this idea for more 3rd party scripts, especially tracking ones?

You may want to market this as something closer to a 'defer until idle' so it insinuates it's an essential task that can be lower in priority of browser execution. At the moment it does feel like I should start developing a monero miner to monetize my website with it.

The logo made me think it's called "oldle Task"

There's lots of confusion what this is. Basically browser runs a giant eventloop. Whenever you call async function in javascript, it gets put into a queue, and called by the event loop (usually the next execution). This basically makes it so that the async call gets tagged with metadata that tells the event queue "Don't call me unless you have nothing else to call". So basically it keeps the async call at the end of the queue until it's the final call, and that's when the eventloop will call it. The subject is quite misleading as it is not really about idle.

I do not understand this hatred agains browsers or javascript in this thread. It is not like the author has invented the world and is now responsible for it.

Btw. I made a similar tool that lets you wrap calls to resource X and then run call Y when X is idle. For example you can de-prioritise network requests or database writes. https://github.com/pubkey/custom-idle-queue