0.1What is Node.js?
The essentials in 30 seconds
- Node.js = JavaScript outside the browser: the same language as on the front end, via the V8 engine, for servers, APIs and tools.
- Non-blocking asynchronous model: a slow operation does not stop the program — Node registers a callback and moves on.
- Single-threaded but thousands of connections: the event loop calls back each function when its result arrives.
Running mini-case — Salim places his first server tool
Salim, a junior developer in Algiers, only knows browser JavaScript. His manager asks him for a small server that answers requests from a page. Salim discovers that Node.js runs his JavaScript on the server thanks to the V8 engine, that reading a file does not block the program there, and that the event loop orchestrates the callbacks. He notes on a card "JS everywhere, non-blocking, event loop" and picks his first test: display a message then simulate a slow operation without blocking.
Self-contained case for this section: it returns in the lesson, diagram, script and 48h challenge of section 0.1.
1. JavaScript outside the browser
Node.js is a runtime environment that runs JavaScript outside the browser, notably on the server. It combines the V8 engine (Chrome's fast JavaScript engine) with a system-access library (files, network). Salim gets the idea: he keeps his front-end language and uses it to write a server, an API or a command-line tool. This is "full-stack JavaScript": one language for the whole web.
2. Non-blocking async and the event loop
What defines Node is its non-blocking asynchronous event loop model. Many server tasks consist of waiting: database, file, network. Instead of waiting passively, Node registers a function to call back (a callback) when it is ready and immediately moves on to something else. The event loop keeps turning: it runs the available code and triggers each callback as soon as its operation finishes. Salim remembers the picture: taking the next order instead of lingering in the kitchen.
3. Single-threaded, strong at I/O, weak at heavy computation
As a result: Node is single-threaded for your code but handles thousands of simultaneous connections, because it never stays blocked waiting. It excels at I/O-intensive work (web servers, APIs, real time) and is less suited to CPU-intensive work (long computations that would hog the single thread). Everything else — callbacks, Promises, async/await — follows from this model. Salim wrote it at the bottom of his card in Algiers: understand the event loop before everything else.
Did you know? The server that never dawdles
Never wait: register a callback and move on.
🔎 Concrete example — 🔎 Concrete example — Blocking vs non-blocking
console.log("Start");
setTimeout(() => {
console.log("Slow operation response");
}, 100);
console.log("End (shown before the response)");Reading: Salim runs this script with Node: "End" appears before "Response", proving the program did not wait.
Lesson: the result arrives later via the callback; the thread stays free in the meantime.
Section vocabulary
- Node.js
- Runtime environment that runs JavaScript outside the browser (on the server), based on the V8 engine plus a system-access library.
Simple example: Salim runs his first server written in JavaScript with Node in Algiers.
What it is not: a different language from browser JavaScript.
Reflex: when facing a server or tooling need, ask "can I do it in JS with Node?".
- V8 engine
- Fast JavaScript engine from the Chrome browser, which compiles and runs JS; the heart of Node.js.
Simple example: Salim knows his server-side JS runs on the same engine as his front-end JS.
What it is not: a networking library or a package manager.
Reflex: remember V8 = execution speed, Node = V8 + system access.
- Non-blocking asynchronous
- Model where a slow operation does not block the program: Node registers a callback and moves on at once.
Simple example: Salim starts reading a file and displays what follows without waiting for it to finish.
What it is not: waiting passively for an operation to finish before moving on.
Reflex: always plan "what to do when it is ready" (the callback).
- Event loop
- Central mechanism that orchestrates execution: it starts slow operations and calls back functions when results arrive.
Simple example: Salim pictures the loop serving each response as soon as the file or database answers.
What it is not: an extra thread per user.
Reflex: think "the loop calls back", not "the program waits".
- I/O-intensive vs CPU-intensive
- I/O-intensive: lots of waiting (servers, APIs) where Node excels; CPU-intensive: heavy computations that would block the single thread.
Simple example: Salim reserves Node for an API that reads a database, and rules out massive video encoding.
What it is not: two names for the same thing.
Reflex: classify each need as I/O or CPU before choosing Node.
In practice — In practice — Placing Node.js and its model
- Remember what Node is: an environment for running JavaScript OUTSIDE the browser (servers, APIs, tools), thanks to the V8 engine.
- Spot the "one language" advantage: JavaScript on both front AND back end (full-stack JS), like Salim in Algiers.
- Understand the non-blocking model: run the example script and notice that "End" arrives before the response.
- Place the right use cases: Node shines for I/O (web servers, APIs, real time), less for heavy CPU computations.
Ready-to-say script — explain Node to a colleague (30 s)
"Node is our JavaScript running on the server thanks to the V8 engine. When it reads a file or queries a database, it does not wait: it registers a callback and processes what follows, and the event loop calls back when it is ready. A single thread handles plenty of requests, perfect for our APIs."
Say it with the example script in front of you; show the display order Start, End, Response.
Copy-paste template — observe non-blocking
console.log("Salim starts reading");
setTimeout(() => {
console.log("Reading done: Salim resumes here");
}, 50);
console.log("Salim continues without waiting");Coming from the front end
You already know browser JS: focus on what changes (no DOM, event loop, I/O) and run the example script to see the real order.
Total beginner
With no JS background: rerun the script three times changing the delay (50, 200, 0) and note the constant order Start, continuation, response — the non-blocking intuition.
Pair in Algiers
Salim has his colleague guess the display order before running it: whoever gets it wrong explains the event loop on the board.
Architecture choice
Before a project: classify the need as I/O (API, server, real time → Node fits) or heavy CPU (massive computation → offload elsewhere).
✓ Best practices
- Think "one language" for front and back end (full-stack JS).
- Reserve Node for I/O tasks (servers, APIs, real time).
- Understand the event loop before everything else.
✗ Common pitfalls
- Believing single-threaded = one user at a time.
- Running a heavy CPU computation that blocks the event loop.
- Forgetting that async (callbacks, Promises) follows from this model.
Key takeaways
- Node.js runs JavaScript OUTSIDE the browser (servers, APIs, CLI tools) via the V8 engine — ONE language for front AND back end.
- NON-BLOCKING ASYNCHRONOUS model: slow operations do not block — Node registers a callback and moves on.
- The EVENT LOOP orchestrates everything; Node is SINGLE-THREADED but handles thousands of simultaneous connections.
- Excellent for I/O (web servers, APIs, real time); less suited to CPU-intensive tasks.
48h challenge — apply tomorrow
Run Salim's non-blocking script, change the delay twice, and explain out loud why "End" arrives before the response.
- I can explain Node.js (server JS via V8) with an example.
- I ran the script and observed the non-blocking order.
- I can say when Node fits (I/O) and when it does not (heavy CPU).
Frequently asked questions
Node.js is single-threaded: how can it handle thousands of users at once?
Distinguish "running code" from "waiting for a slow operation". A server spends most of its time waiting (database, file, network). A blocking server would devote its thread to that passively. Node, non-blocking, delegates the operation to the system, registers a callback and immediately hands back control: the thread processes the next request. The event loop runs each callback as soon as its operation finishes. Like in a restaurant where a good waiter takes orders in a row and serves each dish when the kitchen signals it is ready. Limit: a heavy CPU computation hogs the thread and blocks everything.
When should you choose Node.js, and when should you prefer another technology?
Node shines for: I/O-intensive applications (REST APIs, back ends that read from a database), real time (chat, notifications), full-stack JS teams (one language), microservices and tooling. It is less suited to CPU-intensive tasks (scientific computing, massive image processing, machine learning) that would hog the single thread — then prefer other platforms or offload those computations to specialized services. The right choice depends on the problem (I/O vs CPU), the team and the ecosystem.
What defines the Node.js model?