Content updated
By the end, you can…
- Scheduling a callback does not run it now. The current synchronous work finishes first.
- Predict the example's result, change one part, and verify the behavior in your own script.
One idea at a time
Ordinary JavaScript statements run synchronously, one after another. Some browser operations, such as timers and network requests, arrange for a result or callback later. This is asynchronous behavior. The current script can continue rather than waiting in place for the timer or response. It does not mean all JavaScript instructions run at the same time.
A callback is a function supplied to another operation. With setTimeout, the browser schedules that function after a delay. The delay is a minimum scheduling threshold, not a guarantee of an exact execution time. The main thread is where the browser runs this page’s JavaScript and much of its interface work. A busy main thread or browser scheduling can make the callback run later. Even a zero-delay timer waits until the current synchronous work finishes.
What to remember first
Scheduling a callback does not run it now. The current synchronous work finishes first.
Read the code before trying it
setTimeout(callback, delay)Schedule one callback- delay is in milliseconds: 1000 milliseconds is one second, so 300 is three-tenths of a second. Pass the function itself instead of calling it while scheduling.
clearTimeout(id)Cancel a pending timer- Keep the identifier returned by setTimeout and pass it here before the callback runs.
setInterval(callback, delay)Schedule repeated callbacks- Use clearInterval with its returned identifier to stop repetition. Repetition is not perfectly timed.
synchronousRun as current work- A long loop still blocks interaction; putting unrelated work in a timer does not make the loop faster.
callback queueWait for a chance to run- A ready timer callback cannot interrupt currently executing JavaScript.
Walk through an example
console.log("1. Start");
setTimeout(() => {
console.log("3. Timer callback");
}, 300);
console.log("2. Continue now");Start is logged immediately. setTimeout registers a callback and returns, so Continue now appears next. After the delay and when JavaScript can run it, the callback logs Timer callback. The code's position on the page is not the same as the order of asynchronous output.
See it happen: try a small change
Predict the result, choose a version, then compare the code and output. Try the controls when the example has them. Each version starts fresh.
Code to notice
console.log("Start");
setTimeout(() => console.log("Later"), 300);
console.log("Continue");Live result
What changed: Start and Continue appear first. Later follows when the scheduled callback can run.
Look a little closer
Do not use a large loop to create a delay. It keeps the main thread busy and can freeze controls. A timer lets the browser do other work before returning to your callback, but the callback itself still needs to be short enough not to block the interface. CPU-heavy work needs a different design, such as a worker.
A repeating timer needs cleanup. The interval variant deliberately stops after three ticks, so the preview does not run indefinitely. Choosing another variant or resetting also discards the isolated document. In your own page, cancel timers when their work is no longer needed rather than leaving background repetition running forever.
Try it in your own project
Use your existing script and Console. Predict the order with a 300ms delay, then with zero. Replace that script with the three-tick interval and wait long enough to confirm it stops. Reloading starts a fresh run.
The interactive preview runs in its own isolated document. Its Output panel mirrors console.log messages; it is not a full DevTools console. Choosing another version or resetting starts a fresh example and does not edit your local files. Read any simulation label: storage and request demonstrations explain their offline substitutes, while the written local examples use the real browser APIs.
A common wrong turn
setTimeout(showMessage(), 300) calls showMessage immediately and passes its result. Use setTimeout(showMessage, 300) for a named callback. Also do not assume a variable assigned inside a future callback already has that value on the next synchronous line.
Your turn: understand asynchronous JavaScript
Print an immediate message, a second immediate message, and one delayed message in a predictable order.
Try this in your own HTML and JavaScript files, then open the page in a browser. There is no separate checked practice for this task yet.
- Write the three-message example and predict its output before running it.
- Change the delay to zero and confirm the callback still follows the synchronous logs.
- Create an interval that logs three times and then calls clearInterval. Confirm no fourth tick appears.
Go to the source
Examples are authored for Tuklas and checked with code and reference documentation. This is not a claim of independent human review. Suggest a correction.