Node.js Isn’t Completely Non-Blocking

Node.js was not invented just to “run JavaScript on the server.” It was created to solve a real pain point.

Traditional web servers often spawned a new thread per connection, but most of the time those threads were just sitting idle, waiting for TCP responses, database queries, or file system I/O. Memory was wasted, context switching increased, and scalability became expensive.

Node.js approached this differently with the Event Loop: a single-threaded, non-blocking I/O model built for concurrency. Instead of waiting, the runtime keeps moving and handles work when operations are ready.

But what happens when we block that single thread? What happens when CPU-heavy code, bad patterns, or synchronous operations freeze the event loop?

In this talk, I’ll explore Node.js from the fundamentals to its internals, how the event loop works, what actually blocks it, where Node.js performs poorly, and where it is commonly used the wrong way.
How C++ library helping the nodejs (libuv), how Worker Threads help solve Node.js pain points by offloading CPU-intensive tasks from the main thread, keeping the event loop responsive, and allowing true parallel execution when needed.

• How Node.js works under the hood

• Understanding of the Event Loop and execution flow

• The difference between blocking and non-blocking operations in JavaScript

• How threads and the internal thread pool are used inside Node.js

• How Worker Threads solve CPU-bound bottlenecks