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