Node.js Architecture and the V8 Engine

Objectives

By the end of this lesson, you should be able to:

• Explain what Node.js actually is, beyond “JavaScript on the server”
• Describe the role the V8 engine plays
• Explain why Node.js is well suited to handling many connections at once

💡 Why this matters: Understanding what Node.js actually is, not just “JavaScript that runs outside the browser”, explains a lot of behavior covered in the rest of this module, especially the event loop in the next lesson.

What Node.js Actually Is

Node.js is a JavaScript runtime, a program that can execute JavaScript code outside of a browser. It’s built from two main pieces: the V8 engine (the same JavaScript engine that powers Google Chrome), which actually parses and executes JavaScript code, and a set of additional APIs and libraries (the fs, http, process, and other modules from Module 4) that V8 alone doesn’t provide, since V8 by itself has no concept of files, networking, or an operating system at all.

Node.js is what connects V8 to the underlying operating system, giving JavaScript the ability to read files, open network connections, and do everything a real backend needs, capabilities a browser deliberately doesn’t expose to JavaScript for security reasons.

The V8 Engine

V8 is written in C++ and compiles JavaScript directly to machine code rather than interpreting it line by line, part of why modern JavaScript execution is fast. V8’s job, inside Node.js, is narrowly scoped: parse JavaScript, execute it, manage memory. Everything else, file access, networking, timers, is Node.js’s own layer, built on top of V8, not part of V8 itself.

This separation matters conceptually: the JavaScript language (syntax, Array.prototype.map, Promise, everything from Module 2) comes from V8, and is identical whether running in Chrome or in Node.js. Anything involving files, servers, or the operating system is Node-specific, and simply doesn’t exist in a browser’s JavaScript environment.

Why Node.js Handles Many Connections Well

Node.js runs JavaScript on a single thread, one line of code executing at a time, no true parallel execution of JavaScript itself. This sounds like it should be a bottleneck for a server handling many simultaneous requests, but Node.js is built specifically to avoid that problem: any operation that would normally involve waiting, reading a file, querying a database, waiting for a network response, is handed off to be handled asynchronously (using exactly the promises and async/await patterns from Module 2), freeing the single thread to keep handling other work in the meantime rather than sitting idle.

This is the architectural idea the next lesson, the event loop, explains in full: how a single thread manages to stay responsive while many operations are in flight at once.

Try It

1. Explain, in your own words, the difference between “the JavaScript language” and “what Node.js adds on top of it.”
2. Explain why a browser doesn’t give JavaScript direct access to the file system, but Node.js does.
3. Explain, at a high level, why running JavaScript on a single thread doesn’t automatically mean a Node.js server can only handle one request at a time.

Recap

• Node.js is a JavaScript runtime built from the V8 engine (executing JavaScript) plus additional APIs (file system, networking, and more) that V8 alone doesn’t provide.
• The core JavaScript language comes from V8, identical in the browser and in Node.js, everything OS-related is Node’s own addition.
• Node.js runs JavaScript on a single thread, but hands off waiting-heavy operations asynchronously, keeping that thread free to handle other work.

Next lesson: the event loop, the mechanism that actually makes this possible.