Advertise with Us|Sign Up to the Newsletter

Spring Spotlight 2026 is live and we’ve rounded up the top updates for developers. See what's new for the HubSpot Developer Platform! Ship faster with AI coding tools like Cursor, Claude Code, and Codex.

Build MCP-powered AI connectors, run serverless functions with support for UI extensions, and use date-based versioning to streamline roadmap planning.

📢 Important: WebDevPro is Moving to Substack

We’ll be moving WebDevPro to Substack soon.Once the transition is complete, all future issues will come from packtwebdevpro@substack.com.

To make sure the newsletter continues reaching your inbox, please add this address to your contacts or whitelist it in your mail client. No other action is needed. You’ll keep receiving WebDevPro on the same weekly schedule.

Substack will also give you more control over your subscription preferences if you decide to adjust them later.

Welcome to this week’s issue of WebDevPro!

Node.js is often chosen for its ability to handle concurrent workloads efficiently. Its event-driven, non-blocking architecture allows applications to process multiple operations without waiting for each one to complete. This model is particularly effective in I/O-heavy systems where responsiveness matters more than sequential execution.

Because of this, there is a widespread assumption that Node.js applications will perform well under load by default. In practice, that assumption depends on one critical condition: the application must remain non-blocking.Once blocking behavior is introduced, the system begins to behave very differently.

Blocking code does not always cause immediate failures. In developmentenvironments,where concurrency is limited, the system may appear stable. Requestscomplete,responses are returned, and nothing seems obviously wrong. This creates a false sense of confidence in how the application will behave in production.

Under real-world conditions, however, multiple operations occur simultaneously, and the event loop becomes a shared dependency across all of them. At that point, the cost of blocking becomes visible. Delays accumulate, responsiveness drops, and the system begins to struggle under load. The issue is not simply that blocking code exists, but how it interacts with the event loop and how that interaction scales.

Before we get into it, here’s this week at a glance:

In Node.js, all JavaScript execution happens on a single thread, coordinated by the event loop. The event loop continuously processes tasks by retrieving them from a queue, executing them, and delegating work when possible so that execution can continue without interruption. This model works efficiently because it assumes that tasks will be short-lived and non-blocking.

Blocking code violates this assumption. When a blocking operation is executed, the event loop cannotproceedto the next task until the current one completes. This does not simply delay a single operation. It prevents all other pending tasks from executing during that time, effectively pausing the system’s ability to make progress.

The impact is broader than it first appears. Callbacks that are ready to run remain in the queue. Timers do not fire at expected intervals. Incoming requests must wait before they can even begin execution. What appears to be a local delay becomes a system-wide bottleneck.

This shared delay is what makes blocking code particularly problematic in Node.js. In systems with multiple threads, delays can be absorbed or distributed. In Node.js, the delay is centralized. A single blocking operation affects everything else that depends on the event loop.

Synchronous APIs are often attractive because they simplifyreasoning aboutcode. Execution flows in a straight line, making it easier to follow and debug. This simplicity can be beneficial in scripts or isolated tasks where concurrency is not a concern.

In an event-driven system like Node.js, however, synchronous APIs introduce a significant limitation. Because theyexecute onthe main thread, they block the event loop until they complete. During this time, no other operations can be processed, regardless of how unrelated they may be.

This creates a disconnect between how the code appears and how it behaves under load. The code may look efficient and predictable, but its execution forces all operations into a sequential pattern. Instead of handling multiple tasks concurrently, the system processes them one at a time.

The result is reduced flexibility in how work is handled. As more operations depend on the event loop, the impact of synchronous APIs becomes more pronounced. What begins asa simple designchoice can evolve into a system-wide constraint.

Blocking behavior is not limited to I/O operations. CPU-intensive tasks can have an even greater impact, particularly when executed synchronously. These operations consume the main thread for their duration, preventing the event loop from processing other tasks.

The book illustrates this with a cryptographic key generation example, where a synchronous function is executed repeatedly. Each iteration runs on the main thread, and the cumulative effect is a prolonged period during which theeventloop is unavailable.

performance.mark("start-sync");
for (leti= 0;i< 10000;i++) {
generateKeyPairSync("rsa", {
modulusLength: 1024,
});
}
performance.mark("end-sync");
performance.measure("generateKeyPairSync", "start-sync", "end-sync");

In this scenario, the cost is not just the execution time of a single operation, but the accumulation of blocking across many iterations. The event loopremainsoccupied for the entire duration, preventing any other work from progressing.

performance.mark("start-async");
for (leti= 0;i< 10000;i++) {
generateKeyPair("rsa", {modulusLength: 1024 },
() => {});
}
performance.mark("end-async");
performance.measure("generateKeyPair", "start-async", "end-async");

The asynchronous version changes how the work is executed. Instead of occupying the main thread, the operations are delegated, allowing the eventloop toremain available. This difference has a direct impact on system responsiveness, especially under load.

The difference between synchronous and asynchronous execution is not just conceptual. The bookdemonstratesthat the impact can be measured andobservedin practice. The synchronous version of the operation takes significantly longer and blocks execution entirely.

The asynchronous version, by contrast, allows the system to continue processing other tasks while the work is being performed. This leads to betterutilizationof system resources and improved responsiveness.

This distinction changes how performance should be evaluated. In Node.js, performance is not only about how quickly a single operation completes. It is about whether the system can continue to process other work during that time.

A fast operation that blocks the event loop can still degrade system performance if it prevents other tasks from progressing. Conversely, a slower operation that does not block may have less overall impact on system responsiveness.

Blocking behavior becomes more problematic as concurrency increases. In low-load environments, tasks are processed with minimal overlap, and delays may not be noticeable. The system appears stable because there is little competition for the event loop.

As the number of concurrent operations grows, the situation changes. Multiple tasks begin to depend on the event loop at the same time. Each task expects to be processedin a timely manner, and blocking operationsdisruptthis expectation.

When a blocking operation runs, it prevents the event loop from servicing other tasks. These tasks begin to accumulate in the queue, increasing waittimesand reducing overall throughput. The system becomes less responsive as more work is added.

This is why blocking issues often appear only under load. The system needs sufficient concurrency for the delays to become visible. Once that threshold is reached, the impact becomes more pronounced, and performance begins to degrade more rapidly.

A common misconception is that using asynchronous syntax automatically makes an operation non-blocking. Wrapping a function in async/await or a callback does not change how the underlying work is executed.

The book emphasizes that async syntax controls how results are handled, not how the work itself is performed. If the underlying operation is synchronous and CPU-intensive, it will still block the event loop.

This distinction highlights the difference between code structure and execution behavior. A function may appear asynchronous in form while still behaving in a blocking manner in practice.

Understanding this difference is essential foridentifyingperformance issues. Changing syntax without addressing the underlying execution does not resolve the problem.

In some cases, improving performance is not about changing how an operation executes, but reducing how often it runs. The bookdemonstratesthis with an example where repeated computation is replaced with a caching approach.

Instead of recalculating an expensive result for every request, the system stores the result and updates it periodically. This reduces the number of times the operation is executed, lowering the load on the event loop.

letcachedSignature= null;
const app =Express();

constsigningMiddleware= (_req, res, next) => {
if (!cachedSignature) {
console.info("Signature is not cached");
cachedSignature=signData(Date.now().toString());
setInterval(
() => (cachedSignature=signData(Date.now().toString())),
10000);
}

res.setHeader(
"X-Signature", `data=${cachedSignature.data.toString()};kid=${cachedSignature.keyId};sha512=${cachedSignature.signature}`);
next();
};

This approach shifts the focus from execution style to execution frequency. By reducing repeated work, the system becomes more efficient without changing how the operation itself is implemented.

Blocking code is often easier to write and reasonabout. Its linear execution model provides clarity and predictability, making it attractive in many situations.

However, this simplicity comes at a cost in systems that rely on concurrency. Blocking operations limit the ability of the event loop to process multiple tasks efficiently, reducing overall system responsiveness.

The trade-off is not simply between synchronous and asynchronous code. It is between local simplicity and system-wide performance. A piece of code that is easy to understand in isolation may introduce constraints that affect the entire application.

As systems scale and concurrencyincreases, this trade-off becomes more significant. Decisions that seem minor at the code level can havesubstantialimpactatthe system level.

Node.js relies on a responsive event loop to handle concurrent operations effectively. Blocking code disrupts this model by introducing delays that affect all tasks, not just the one being executed.

The impact of blocking behavior is not always immediate, but it becomes clear under load. As concurrency increases, the system’s ability to process work efficiently depends on keeping the event loop free.

Ifyou’dlike to read more on this, Node.js Design Patterns explores these ideas in depth, especially around asynchronous behavior, performance, and the architectural decisions behind scalable Node.js systems.

🎬 Add unique animations to your React apps

Building engaging UIs often means going beyond basic transitions.Animataoffers a collection of 100+ animation-focused React components, including effects like animated beams, spreading cards, and even a Slack-style intro screen.

It’sa handy resource if you want to add more personality to your UI without building complex animations from scratch.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

👋 Advertise with us
Interested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email, and our team will get in touch with the next steps.