Why Did Node.js Even Need to Exist?
You already know JavaScript. You know it runs in the browser. The entire purpose was simple make web pages respond to user actions. But have you ever think why does it run in the browser at all?
Because something inside the browser is reading your JavaScript line by line and telling the computer what to do. That something is called a runtime engine. In Chrome, it's called V8. In Firefox, it's SpiderMonkey. Think of it as a translator JavaScript speaks, the engine listens, and the computer acts.
Now here's the problem. That translator only lived inside the browser. You couldn't take it outside. You couldn't run JavaScript on a server, talk to a database, read files on disk, or build an API. JavaScript was essentially trapped.
Ryan Dahl looked at this in 2009 and said what if we break it out? He took V8 out of Chrome and wrapped it with something extra. That wrapper became Node.js.
How Nodejs was build?
Ryan noticed that Google's V8 engine inside Chrome was fast, open-source, and not tied to the browser in any fundamental way. It was just a C++ library that could compile and execute JavaScript. So he pulled it out.
But V8 alone was only half the answer. He needed to give it hands. He wrapped V8 with a C library called libuv, which was built specifically to handle I/O operations file system calls, network connections, DNS lookups across different operating systems in a non-blocking way.
That combination is the entire foundation of Node.js.
V8
You don't need to understand V8 deeply to use Node.js. But a high-level picture helps.
V8 job is to take JavaScript code and turn it into something the CPU can actually. V8 reads your code, figures out what it's doing, and translates it into native machine code on the fly. This is called JIT(Just in time) compilation.
The result is that JavaScript runs fast compared to what anyone expected from a scripting language. V8 also handles memory management for you allocating it when you create objects, cleaning it up when you're done with them, through a process called garbage collection.
When Node.js runs your code, V8 is the one actually executing it. Node.js just sets the stage.
Event Drive Architecture
Let's use an analogy. Imagine a restaurant.
Traditional servers like PHP or Java with thread-per-request models work like a waiter who takes your order and then stands next to your table, doing absolutely nothing, until your food comes out of the kitchen. During that entire waiting time, that waiter is occupied. If 1,000 customers walk in, you need 1,000 waiters just standing around.
Node.js works like a smart waiter. They take your order, walk it to the kitchen, and immediately go take the next table's order. When the kitchen shouts "order up!", the waiter gets notified and delivers it. One waiter can handle 100 tables because they're never standing around waiting.
That's event-driven, non-blocking I/O. Instead of stopping everything while waiting for a database response or a file read, Node.js registers a callback and moves on. When the result is ready, it comes back via the event loop.
This is the reason Node.js can handle tens of thousands of concurrent connections on a single server process while traditional multi-threaded servers would be crushed under that load. Not because Node.js is faster at computation it's often not. But because it never idles.
Now here's how the Node.js runtime architecture actually fits together:
General use cases
I hope you get to know something valuable from the article.
I’m currently deep-diving into the JavaScript, building projects and exploring the internals of the web. If you're on a similar journey or just love talking about JavaScript, let’s stay in touch!
Keep coding and keep building.
