Repository files navigation

A polyfill for Task Worklet - a proposed API for defining and invoking coordinated, threadpooled background tasks with minimal transfer overhead.

A lot of what we do in modern web applications touches the DOM in some way.Improving the performance of DOM-bound code is difficult because issues generally stem from layout and paint cost rather than actual script execution overhead.Task Worklet attempts to define a highly ergonomic way to offload all of the work an application needs to do thatdoesn't rely on the DOM, while making it incredibly easy to move data between the UI thread and background threads.

In addition to ergonomics, the design of Task Worklet allows for an implicit data flow graph to be formed based on how tasks are linked together to form dependencies on one another. When combined with pooling and a centralized registry for task processors, this enables an algorithm to distribute work across multiple threads, automatically maximizing concurrency and minimizing transfer overhead.

Demo:Realtime JS compilation, bundling & compression

First, install the script vianpm install task-worklet or grab it fromunpkg.

By default, thetask-worklet ships as an npm module that exports theTaskQueue interface.

If you'd prefer to "install" it aswindow.TaskQueue, go fortask-worklet/polyfill:

<scriptsrc="https://unpkg.com/task-worklet/polyfill"></script>

Once you have it imported/installed, we can start interacting with theTaskQueue:

// create a queue a max threadpool size of 1:constqueue=newTaskQueue();// add a Task Worklet:queue.addModule('/fetch-worklet.js').then(()=>{/* loaded */})consttask=queue.postTask('fetch','https://example.com/data.json');console.log(task.state);// pendingawaitsleep(1);console.log(task.state);// scheduled// now we'll ask for the result back. This bumps up the priority// of the task and sends its result to the main thread once complete:constresult=awaittask.result;console.log(result)// { ..some data.. }

Here's the key:task.result is a lazy getter. If you don't ask for a Task's result by accessing.result, it will be kept in whatever background thread ran the task until it's needed.

Why keep task results in the thread that ran the task?That's the best part: we can passTask instances topostTask(), and instead of "pulling" the result of a task back to the main thread and sending it on to the thread that's running that second task, the second task will be routed to the thread that already has the first's result waiting:

constdata=q.postTask('fetch','https://example.com/data.json');constsubset=q.postTask('filter',data,['items','count']);// we only end up with the subsetted data on the main thread:console.log(awaitsubset.result);