DEV Community: Yuvaraj Yuvaraj

Chapter 2: Comparing Node.js, Java and C-sharp

Yuvaraj Yuvaraj — Sun, 02 Aug 2026 19:03:26 +0000

JavaScript is a synchronous, single-threaded language.

That means only one piece of JavaScript code can execute at a time.

When I first learned this, I thought,

"Wait... if JavaScript can only execute one task at a time, then how is Node.js capable of handling thousands of requests?"

That question stayed in my mind for quite a while.

So I started digging deeper.

Before we continue, forget about the image below for a moment. I simply want to explain what was going on in my head.

From everything I had learned so far, my understanding was this:

JavaScript executes only one task at a time.
File operations, database queries, and network requests take time.
Yet Node.js somehow doesn't stop while waiting for those operations.

That immediately raised another question.

Who is actually doing all this work?

If JavaScript can execute only one piece of code at a time, who is reading files from disk? Who is talking to the database? Who is sending HTTP requests?

I later discovered that operations such as file system access, DNS lookups, cryptographic operations, compression, and several other long-running tasks are delegated by Node.js to its underlying runtime instead of forcing the JavaScript thread to wait.

At this stage, I wasn't trying to understand libuv, the Event Loop, or the Thread Pool.

I simply wanted to understand why Node.js behaved so differently from the backend technologies I had heard about before.

Then I came across another term that almost every Node.js article mentioned.

Non-blocking I/O

Initially, I didn't understand why people considered it such a revolutionary idea.

So instead of memorizing the definition, I compared it with what I already knew about traditional server applications.

Let's use a simple database query as an example.

Imagine a request arrives and your application needs to fetch some data from a database.

The database might take 100 milliseconds, 500 milliseconds, or even a few seconds to respond depending on the workload.

Now think about what your application does during that waiting period.

How traditional servers handled this

Historically, many backend servers—including Java applications before the widespread adoption of asynchronous programming—typically used a thread-per-request model.

When a request arrived:

A thread was assigned to that request.
The thread executed your application code.
When it reached a database query, the thread waited until the database returned the result.
Only after receiving the response could the thread continue executing the remaining code.

The important thing to notice is that the thread remained occupied while waiting.

It wasn't performing useful work.

It simply stayed blocked until the I/O operation completed.

If thousands of requests arrived simultaneously, the server required thousands of threads—or the requests had to wait until a thread became available.

Creating and managing many operating system threads consumes memory, increases context switching, and eventually limits scalability.

This was perfectly acceptable for many workloads, but it introduced overhead as traffic increased.

How Node.js approaches the same problem

Node.js takes a very different approach.

When JavaScript reaches an operation that involves waiting—such as reading a file, querying a database through asynchronous APIs, performing a DNS lookup, or making a network request—it doesn't keep the JavaScript thread idle.

Instead, Node.js delegates the waiting operation to the underlying operating system or to its runtime components.

The JavaScript thread becomes free almost immediately.

Instead of waiting, it starts processing the next request that has already arrived.

Later, when the database finishes its work, Node.js is notified.

Only then does JavaScript continue executing the callback, Promise, or async/await continuation associated with that operation.

This is the core idea behind non-blocking I/O.

The JavaScript thread spends far less time waiting and far more time executing actual application logic.

Why this became a huge advantage

This was the moment everything finally clicked for me.

The biggest advantage isn't that databases suddenly became faster.

The database still takes exactly the same amount of time.

The real advantage is that Node.js refuses to waste the JavaScript thread while waiting.

Instead of sitting idle for hundreds of milliseconds, the same thread can start handling other incoming requests.

Imagine a restaurant.

A waiter doesn't stand beside one table waiting for the chef to finish cooking.

The waiter takes the order, gives it to the kitchen, and immediately serves other customers.

When the food is ready, the kitchen notifies the waiter, who then delivers the meal.

Node.js works in a very similar way.

While one operation is waiting for I/O, JavaScript is already busy serving other requests.

This allows a relatively small number of resources to serve a surprisingly large number of concurrent connections.

For companies building APIs, chat applications, streaming services, dashboards, or real-time systems, this can significantly improve resource utilization.

Instead of having hundreds of threads sitting idle waiting for databases or files, Node.js keeps its JavaScript execution focused on doing useful work.

But does that mean traditional platforms are outdated?

Not at all.

This is an important point that is often misunderstood.

When Node.js was introduced by Ryan Dahl in 2009, its event-driven, non-blocking architecture was a refreshing alternative to the dominant server models of that time.

However, backend platforms have evolved tremendously over the years.

Modern Java and C# are very different from what they were fifteen years ago.

Modern C# and asynchronous programming

Today, C# provides excellent asynchronous programming through async and await.

When an asynchronous operation reaches an I/O boundary, the executing thread is returned to the .NET Thread Pool instead of remaining blocked.

That thread is then free to execute other requests.

When the I/O operation finishes, another available thread resumes the remaining execution.

This means modern C# applications also avoid wasting threads while waiting for I/O.

The programming model is different from Node.js, but the objective is remarkably similar:

Don't keep valuable threads idle during slow I/O operations.

Modern Java and Virtual Threads

Java has also made major advancements.

With Project Loom, officially introduced in Java 21 (2023), Java now supports Virtual Threads.

Traditional operating system threads are relatively expensive.

Virtual Threads are much lighter.

When a Virtual Thread performs a blocking I/O operation, the Java runtime can suspend that Virtual Thread, release the underlying platform thread, and allow it to execute other work.

Once the database responds, the suspended Virtual Thread resumes execution.

To the developer, the code still looks simple and sequential, but underneath, the runtime efficiently manages thread usage.

This dramatically improves scalability while preserving Java's familiar programming style.

So why do developers still choose Node.js?

After learning all of this, I realized something important.

Choosing Node.js isn't about saying it's "better" than Java or C#.

It's about understanding the trade-offs.

Node.js embraces an event-driven architecture built around a single JavaScript thread for application code.

It excels at workloads with heavy I/O, such as:

REST APIs
Real-time applications
Chat systems
Streaming services
WebSockets
Microservices
API gateways

Java and C#, on the other hand, have evolved to solve many of the historical scalability problems through asynchronous programming, efficient thread pools, and lightweight Virtual Threads.

Today, all three platforms are capable of building highly scalable backend systems.

The difference lies more in their runtime architecture, ecosystem, programming model, and the types of workloads they optimize for.

My biggest takeaway

Initially, I thought Node.js was magical.

I assumed it could somehow make databases respond faster or execute multiple JavaScript statements simultaneously.

Neither of those assumptions is true.

The database is still slow when it's slow.

JavaScript is still single-threaded.

The real innovation is much simpler.

Node.js doesn't waste its JavaScript thread waiting.

Instead, it delegates long-running I/O work to the underlying runtime, continues serving other requests, and comes back only when the operation is complete.

Understanding that one idea completely changed how I viewed backend systems.

It also helped me appreciate that modern Java, C#, and Node.js are all solving the same scalability challenge—keeping expensive computing resources busy instead of letting them sit idle.

Once I understood that, the architecture of Node.js finally started to make sense.

Chapter 1: Introduction to Node - But understanding what system is capable off

Yuvaraj Yuvaraj — Fri, 31 Jul 2026 20:25:49 +0000

Hi everyone! 👋

This is my very first post on dev.to.

I'm Yuvaraj, and I've been writing technical blogs on Medium for a while. I recently decided to start publishing here as well because I love learning in public, and I believe dev.to is the perfect community for that.

I won't claim to be an expert in Node.js. I'd say I'm somewhere in the middle of my journey—comfortable enough to build applications, but still curious enough to question everything happening under the hood.

So, I'm starting a new series where we'll explore Node.js from the ground up—not just how to use it, but why it works the way it does.

Hopefully, we'll both learn something along the way.

Wish me luck! 🍀

The Question That Changed My Perspective

It all started while I was learning Express.js, building APIs, and trying to understand JavaScript's Event Loop and callbacks.

Coming from frontend development, I already understood how JavaScript executes inside Chrome. Naturally, I assumed Node.js worked in almost the same way.

Then I came across something called worker threads and learned that operations like file system tasks don't always behave the way I imagined.

That completely changed my perspective.

I realized I had been using Node.js without truly understanding what was happening underneath.

My First Question: What Is a Thread?

Before trying to understand Node.js, I wanted to answer a much simpler question:

What exactly is a thread?

A simple way to think about it is this:

A thread is a unit of execution. Whenever a program has work to do, that work is performed by a thread.

That immediately led me to another question:

How do threads actually run inside a computer?

To answer that, I had to go back to the basics of computer hardware.

Understanding the Computer First

Every computer (or even your smartphone) has three important components:

RAM

RAM is the computer's working memory.

It temporarily stores the data and program instructions that are actively being used.

You can think of it as the workspace where running programs keep the information they currently need.

It isn't technically "holding threads." Instead, it stores the memory that running processes and their threads use while executing.

Storage (SSD/HDD)

This is where your files live permanently.

Your source code, images, videos, applications, and operating system are all stored here until they're needed.

When you launch a program, the operating system loads the required parts from storage into RAM.

CPU

This is where the actual execution happens.

The CPU executes instructions.

Modern CPUs contain multiple cores, and each core can execute one or more threads simultaneously (depending on the processor and technologies such as Hyper-Threading or SMT).

For example:

A dual-core CPU can execute multiple threads concurrently.
A quad-core CPU can execute even more work in parallel.

This was a huge "Aha!" moment for me.

Then My Curiosity Exploded...

Once I understood this much, my mind was full of questions.

Why node js became popuple, how is it different from java, c#.

Those questions pulled me deeper into understanding operating systems, threads, CPU scheduling, and eventually the internal architecture of Node.js.

If you're curious about exploreation, I think you'll enjoy this journey.

See you in the next post! 👋