WEBVTT

NOTE AI Engineering Visualised: https://understandingdata.com/ai-engineering-visualised/event-loop/

1
00:00:00.079 --> 00:00:09.929
A ten-millisecond timer is a request to wait at least ten milliseconds, and this example shows why its callback still cannot run when that wait ends.

2
00:00:09.980 --> 00:00:20.366
The script prints start, schedules the timer, queues two microtasks, and then holds the thread for eighty milliseconds before printing end, with every line visible in TypeScript.

3
00:00:20.440 --> 00:00:31.199
When our clock reaches ten, the timer becomes eligible in this model, but the current task keeps the thread until eighty, so becoming eligible never interrupts synchronous code.

4
00:00:31.199 --> 00:00:40.867
After the script returns, the microtask checkpoint runs A first, and the timer keeps waiting because the browser drains this queue before selecting another task.

5
00:00:40.920 --> 00:00:51.262
A now appends C behind B, so the same checkpoint runs B and then C, giving start, end, A, B, C, timer in both browsers we tested.

6
00:00:51.340 --> 00:01:02.421
Splitting the work into four chunks changes nothing if each continuation awaits an already fulfilled promise, because those continuations are microtasks and our timer still waits roughly eighty milliseconds.

7
00:01:02.421 --> 00:01:14.403
Task-level yields create a chance to run between chunks: our two browsers ran the timer around forty and twenty milliseconds, showing why yielding improves responsiveness without promising an exact start time.

8
00:01:14.403 --> 00:01:26.159
Keep timer delay, queue eligibility, and callback execution separate, and for expensive work choose task-level yields or a worker, because a promise continuation alone does not give timer tasks a turn.