What Is Node.js? Understanding the Event Loop and Non-Blocking I/O

When I first used Node.js in a project, I knew what the internet told me:

“Node.js is a runtime environment that lets you run JavaScript on the server side.”

It sounded cool, important. But honestly?
I didn’t really understand what that meant.

If you're like me, someone who wants to actually grasp what's happening under the hood, this post is for you. Let's break it down.

First: What Even Is a Runtime Environment?

A runtime environment is simply the setup that allows your code to run.

JavaScript, by itself, is just a language. It needs an environment, a system that can:

• Interpret the code

• Run commands like console.log(), setTimeout()

• Manage memory, timers, and APIs

So when we say “Node.js is a runtime environment,” we mean:

It's the system that allows JavaScript code to execute outside the browser.

Before Node.js…

Before Node.js came around, JavaScript could only run inside web browsers:

• Chrome (using the V8 engine)

• Firefox (using SpiderMonkey)

Browsers provided a JavaScript runtime, but it was limited to interacting with web pages:

• Updating the DOM

• Handling clicks

• Making network requests via fetch

But it couldn’t:

• Read or write files

• Talk to databases

• Create a server

Because browsers are sandboxed, they protect users from malicious code by not giving access to sensitive system features.

Then Came Node.js (2009)

Node.js took the V8 engine out of the browser, and wrapped it with:

• File system access

• Networking capabilities

• HTTP server tools

• And many more built-in modules

Suddenly, JavaScript could run on the server, just like Python, PHP, or Java.

This changed the game: Now you could build full-stack applications using one language - JavaScript, for both the frontend and the backend.

But Running JS on the Server Wasn’t the Only Goal…

Node.js wasn’t just about "JavaScript on the server."
It was also designed to be lightweight, fast, and scalable, perfect for handling many users at once.

Here’s the problem with many traditional server-side languages:
They use multi-threading.
Every new request spins up a new thread.
But if 10,000 people hit your server at once, you’re dealing with 10,000 threads, and that can crash your system or make it painfully slow.

Enter: The Event Loop — Node’s Superpower

Node.js said:

Let’s not create a new thread for every request.
Let’s just use one single thread…
and be really good at asynchronous, non-blocking I/O.

This is where the Event Loop comes in.

What Is the Event Loop?

The event loop is the core mechanic of Node.js that handles async operations like:

• File reads

• Network requests

• Database queries

And it does this without blocking other operations.

Here’s how it works:

Step-by-step:

1. A user hits your Node.js server:
   → “Please read this file!”

2. Node sends that request to the file system.
   It says: “Okay, go do this, and let me know when it’s done.”
   (That’s the non-blocking part.)

3. Meanwhile, the event loop keeps spinning, handling other users and tasks.

4. When the file system finishes reading the file, it says:
   → “I’m done! Here’s the result!”

5. The callback function gets pushed to a queue, and the event loop executes it when the thread is free.

Example Code

const fs = require('fs');

fs.readFile('data.txt', 'utf8', (err, data) => {
  if (err) throw err;
  console.log('File content:', data);
});

console.log('This runs while the file is being read...');

Output:

This runs while the file is being read...
File content: (actual content here)

This works because Node.js doesn’t sit and wait for readFile to finish.
It delegates that task and continues working, thanks to the event loop.

In a Nutshell

When I finally understood how the event loop worked, a lot of things about Node.js started to make sense.
It’s not just about writing JavaScript on the backend; it’s about how Node handles time, tasks, and users really well.

If this helped you connect the dots, you’re already ahead of where I was when I started.