bi-11 — Broader Ideas

Priority systems degrade without governance

Chromium prioritises input highest — and needs anti-starvation logic because strict priority alone produces starvation. The same is true of any priority system you build: queues, job schedulers, feature-flagged rollouts, on-call severities.

Priority systems drift to uniformity unless someone owns the policy. If everything can be marked user-blocking, everything will be.

When you expose a priority API — scheduler.postTask, a job queue, a startTransition equivalent — you are handing a lever to someone who cannot see the whole system. Plan the governance with the API.

Deadlines change design, not just tuning

The 2-second gesture deferral and the 5-minute mobile freeze are policies derived from user behaviour, not from engineering convenience. They are worth citing when someone proposes a background task with no consideration of foreground impact.

Your equivalents: batch windows, retry backoff, prefetch aggressiveness. Each is a bet about what the user is about to do — and each should be stated as such rather than tuned by feel.

Yielding has a cost curve

The naive advice "yield more often" turns upward, because a MessageChannel continuation goes behind unrelated work. scheduler.yield() exists specifically to fix that.

This generalises to every cooperative system: yielding is not free, and yielding to a queue you do not control can starve you. If you implement chunked processing anywhere — a worker loop, a stream transform, a migration script — measure the curve rather than picking an interval.

Next

fw-04 is where this becomes a framework: interruptible rendering is only meaningful because of the scheduling facts established here. fe-01 is the JS-observable half and should precede this module.