npm install knittingNode · Deno · Bunimport { serve } from "@hono/node-server";
import { Hono } from "hono";
import { createPool, isMain } from "knitting";
export const double = (n: number) => n * 2;
if (isMain) {
const pool = createPool({
threads: 1,
})({ double });
const app = new Hono().get("/", async (c) =>
c.json({ result: await pool.call.double(21) })
);
serve({ fetch: app.fetch, port: 3000 });
}await pool.call.double(21)same process, shared memory
Quick start
This Hono route compresses HTML in a worker and returns the compressed size.
import { serve } from "@hono/node-server";import { brotliCompressSync } from "node:zlib";import { Hono } from "hono";import { createPool, isMain } from "knitting";
export const compress = (html: string) => brotliCompressSync(html).byteLength;
if (isMain) { const pool = createPool({ threads: 1 })({ compress }); const app = new Hono().get("/", async (c) => { const html = c.req.query("html") ?? "<h1>Hello from Hono</h1>"; return c.json({ compressedBytes: await pool.call.compress(html) }); }); serve({ fetch: app.fetch, port: 3000 });}Define and export the function at the top level of its module.
Create a pool with one worker and pass it your function.
Use await to get the result, just like any other async call.
npm install hono @hono/node-server knitting
deno add --npm hono @hono/node-server knitting
bun add hono @hono/node-server knittingIn a busy server
When the main thread is busy, even a simple /ping has to wait. Moving React rendering and JWT signing into one worker leaves more room for the main thread to respond.
In this Hono benchmark, /ping responded sooner at the same load, with roughly the same CPU use. The ping route itself stayed on the main thread.
Measured in 15-second runs with one worker. Results depend on your workload and pool size.
Before
/pingWith one worker
/ping/ping response time p99 · lower is better
Working with a pool
Large inputs
Pass ordinary JavaScript values directly. For large buffers, shared memory and buffer references can reduce copying. The available options depend on your worker type.
Isolation
Threads are the default. For stronger isolation, use a separate process inside a sandbox or container. Use importTask to load the task’s code only in the worker.
Errors and timeouts
Use timeouts and abort signals for tasks that support cancellation. For stuck CPU work, set a deadline that terminates the worker. Errors keep their stack traces and causes.
Tasks and timeoutsDebugging
Turn on logs for worker setup, imports, and task activity. Choose which diagnostics to enable; the logger stays unloaded when they’re off.
Configure a poolScheduling
With work stealing, available workers can pick up waiting tasks instead of leaving them queued behind a busy worker. Knitting enables this automatically for compatible pools.
How scheduling works
Examples
Each example includes code and measurements. Workers are useful for CPU work; they usually won’t help code that mostly waits for a database or network response.
Benchmarks and tests
The benchmarks include the setup and methodology. The tests cover shared memory, timeouts, permissions, and worker failures. Found a bug? Open an issue.
Move it into a worker and compare how your app responds.
Knitting ships machine-readable docs at /llms.txt and /llms-full.txt. Read them before generating code.
Workers re-import the task module, including its top-level imports. Keep task modules lean, export every task, and use importTask when code should load only inside the worker.