Suggest an editImprove this articleRefine the answer for “What the term non-blocking means”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**«Non-blocking» means that program execution does not stop while a long operation is in progress: a network request, a timer or a file read.** Instead of waiting, JavaScript hands the operation to an external API (the browser or Node.js) and keeps running the rest of the code, processing the result later, when the callback moves from the queue into a free call stack. This is what keeps the interface responsive and lets a Node.js server serve many requests at once. ```javascript console.log('A'); setTimeout(() => console.log('B'), 2000); // non-blocking console.log('C'); // A, C, B ``` **Key point:** non-blocking means «do not wait, carry on», and the result is handled once it is ready.Shown above the full answer for quick recall.Answer (EN)Image**The term «non-blocking» means that program execution does not stop while a long operation is being awaited**, for example a network request, a timer or a file read. Put simply, non-blocking means «do not wait, carry on running other code». ## Theory ### TL;DR - Non-blocking code does not pause the main thread of execution. - While an asynchronous operation runs «in the background», JS performs other tasks. - It is implemented through the single threaded model, the Event Loop, asynchronous APIs and task queues. - `setTimeout`, `fetch` and `fs.readFile` are non-blocking operations. - A heavy synchronous loop, on the contrary, blocks everything, including the interface. - Node.js is built around non-blocking I/O, which is why one process serves many requests. ### Quick example ```javascript console.log('A'); setTimeout(() => { console.log('B'); }, 2000); console.log('C'); ``` Output: ```javascript A C B ``` `setTimeout` is a non-blocking operation: it does not stop the program, it schedules the callback for later. ### Blocking and non-blocking code The blocking version: ```javascript function sleep(ms) { const start = Date.now(); while (Date.now() - start < ms) {} // blocks the thread } console.log('A'); sleep(2000); console.log('B'); ``` Output (after 2 seconds): ```javascript A B ``` Everything «froze» for two seconds: while `sleep()` runs, neither the interface nor other scripts execute. This is **blocking** code. The non-blocking version with `setTimeout` (see the quick example above) prints `A`, `C`, `B`: the line `C` runs immediately, while `B` waits its turn without occupying the thread. ### How it works under the hood Non-blocking behaviour is achieved through: 1. the **single threaded model** of JS, where everything goes through the Event Loop; 2. **asynchronous APIs** (browser or Node.js ones); 3. **task queues (the callback queue)**, where finished results wait. JS sends the operation (for example `fetch`) to an external API and does not wait, it keeps running the code. When the result is ready, the callback goes back into the queue, and the Event Loop runs it as soon as the call stack is free. ### Non-blocking in Node.js Node.js is built around **non-blocking I/O**. That means: - file, network and database operations are **asynchronous**; - instead of waiting for a result, Node keeps serving other requests. ```javascript const fs = require('fs'); console.log('Start'); fs.readFile('file.txt', 'utf8', (err, data) => { console.log('File has been read'); }); console.log('End'); ``` Output: ```javascript Start End File has been read ``` Reading the file here is **non-blocking**: Node does not wait for it to finish, it runs the rest of the code. ### Why this matters | Approach | What it does | Downside | | --- | --- | --- | | **Blocking** | Runs operations strictly one after another | «Hangs» the thread, slows the interface down | | **Non-blocking** | Lets other tasks run while waiting | You have to be comfortable with callbacks and promises | Asynchrony and non-blocking behaviour make JS responsive and efficient, especially in the browser and in server applications. An everyday analogy: picture a waiter in a cafe. - **The blocking approach:** the waiter stands and waits until the order is cooked, and only then takes the next one. - **The non-blocking approach:** the waiter passes the order to the kitchen and serves other customers while it is being cooked. JavaScript behaves like the second waiter. ### Summary of terms | Term | Meaning | | --- | --- | | **Blocking** | Execution stops until the operation has finished | | **Non-blocking** | Execution continues and the result is handled later | | **Implementation** | Through the Event Loop, asynchronous callbacks and promises | | **Benefit** | Does not «freeze» the thread, fast response | ### Common mistakes - Assuming non-blocking means multithreading: the code still runs in a single thread. - Writing your own `sleep()` on a `while` loop instead of `await new Promise(r => setTimeout(r, ms))`. - Using the synchronous Node.js API variants (`fs.readFileSync`) in code that serves requests. - Doing heavy computation on the main thread: even asynchronous code will not save you from blocking. - Thinking that `await` blocks the thread: it only pauses its own `async` function, the thread stays free.For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.