How React-Style Time-Slicing Keeps UIs Responsive

Quick Recap

In the previous article, we introduced priority-based and layered schedulers, solving the problem of “which tasks should run first.”

However, real-world applications introduce another challenge:
long-running tasks can still block the main thread.

To keep applications responsive, a scheduler must also support:

• Time-Slicing
• Cooperative Scheduling

---

The Problem: Long Tasks Blocking the Main Thread

Imagine this scenario:

The UI thread is executing a large rendering task — for example, updating 5000 list items at once.

That operation might take tens of milliseconds, or even exceed 100ms before finishing.

During that time:

• Mouse movement and keyboard input cannot respond immediately
• The UI may freeze and drop below 60 FPS
• Users experience visible stuttering and lag

Priority alone is not enough.

Even if a task has the correct priority, once execution begins, it can still monopolize the main thread.

---

Time-Slicing

The core idea behind Time-Slicing is:

Split a long task into smaller chunks and periodically yield control back to the main thread.

Workflow

1. A task is divided into smaller chunks
2. After each chunk, the scheduler checks whether there is remaining execution time
3. If not → pause execution and continue later during the next available frame or idle period

This ensures:

• User input and animations remain responsive
• Background work completes progressively over time

---

Cooperative Scheduling

In operating systems, there are two major scheduling models:

• Preemptive Scheduling
• Cooperative Scheduling

In JavaScript’s single-threaded environment, true preemption is impossible.

So frameworks adopt cooperative scheduling instead:

• Tasks voluntarily check whether they should yield (shouldYield())
• If interrupted, the remaining work is re-queued for later execution

This is essentially the strategy used by React Concurrent Mode.

---

Example Implementation

Here is a simplified example of a Time-Slicing + Cooperative Scheduler:

let deadline = 0;

function shouldYield() {
  return performance.now() >= deadline;
}

export function runWithTimeSlicing<T>(
  work: () => T,
  timeSlice = 5
): T | void {
  deadline = performance.now() + timeSlice;

  while (!shouldYield()) {
    const result = work();
    return result;
  }

  // Not finished → continue later
  queueMicrotask(() =>
    runWithTimeSlicing(work, timeSlice)
  );
}

Key Idea

• Each execution is allowed to run for only timeSlice milliseconds
• Once the budget is exceeded, control returns to the browser

This prevents long-running tasks from blocking the main thread entirely.

---

Combining Time-Slicing with Priorities

On top of a layered priority scheduler, we can integrate Time-Slicing strategies:

• Immediate / High Priority

  • Execute immediately without slicing

• Normal Priority

  • Use time-slicing and process incrementally

• Low / Idle Priority

  • Use requestIdleCallback
  • Run only when the browser is idle

This allows the system to balance:

• Real-time interactions
• Heavy background updates
• Overall UI smoothness

---

Time-Slicing Scheduler Flow

---

Final Thoughts

Priority scheduling solves the question of:

“Which task should run first?”

Time-Slicing and Cooperative Scheduling solve another equally important problem:

“How do we avoid blocking the UI?”

Together, these techniques allow systems such as Signals, React, and Vue to remain responsive even under massive update workloads.

In the next article, we’ll explore DevTools and Diagnostics, including:

• Inspecting reactive nodes
• Dependency graph visualization
• Render counters
• Hotspot tracing
• Scheduler debugging tools

These tools help us better understand how signals and schedulers behave in real-world applications.