Node.js: Running JavaScript on the Server

A Scoreboard That Only Updates in Your Own Browser

Imagine you and three friends are building a live scoreboard for your school's inter-house cricket match, using only what you have learned so far: HTML, CSS, and JavaScript that runs inside a web browser. You write a script that listens for a button click, adds runs to a variable, and updates the number shown on the page. It works perfectly — on your laptop. But when your friend opens the same page on her phone to check the score, she sees the number stuck at zero, no matter how many runs you have added on your screen.

This is not a bug in your code. It is a boundary you have not yet learned how to cross. JavaScript running in a browser lives inside that one browser tab. The variable holding the score exists only in your laptop's memory, in your session. Your friend's phone has no way to see it, because nothing is watching both of you at once. Each browser is an island. For the scoreboard to be shared, something needs to sit in the middle — a program that is always running, that both your laptop and your friend's phone can send messages to, and that remembers the score even after you close your browser tab. That "something in the middle" needs to be a program too, and for years, JavaScript could not be that program, because JavaScript only existed as a guest living inside browsers. Node.js is the tool that changed this: it lets JavaScript step outside the browser and run as an independent program on a computer that is not showing you a webpage at all — a server.

Client and Server: Renaming What You Already Understand

Before going further, it helps to formalize an idea you already use every day without naming it. When you open IRCTC to check a train's seat availability, your phone is not calculating seat numbers itself. Your phone sends a request across the internet ("how many seats are left on train 12951?"), a computer somewhere in a data center looks up the real, shared, single source of truth, and sends back an answer. Your phone is the client — it asks. The distant computer is the server — it answers, and it holds the data that every client shares. This request-answer pattern is called the client-server model, and it is the reason a train seat that just got booked by someone in Chennai instantly disappears from your screen in Delhi: both of you are asking the same server, not keeping your own private copy.

Your scoreboard problem has exactly this shape. The fix is not "write better browser JavaScript" — it is "add a server that both browsers talk to." Historically, that server-side program would have been written in a completely different language: PHP, Java, Python, or C#. You would need to learn a second programming language just to build the "answering" half of your application, even though you already knew JavaScript for the "asking" half. Node.js removes that requirement. It lets you write the server in the same language you already use for the browser.

What Node.js Actually Is: A Runtime, Not a Language

Here is a distinction that trips up almost every student meeting this topic for the first time, so let us get it exactly right. Node.js is not a programming language. The language is still JavaScript — the same syntax, the same if statements, the same functions and arrays you already write. What Node.js provides is a runtime environment: the surrounding machinery that takes your JavaScript code and actually executes it, plus a set of extra abilities the browser never gave you.

To see why this distinction matters, think about what a browser secretly gives JavaScript. When you write document.getElementById("score"), that works only because the browser hands JavaScript a ready-made object called document representing the webpage. JavaScript the language has no idea what a webpage is — the browser is the one supplying that capability. Underneath, every major browser uses an engine to actually read and execute your JavaScript code at high speed; Chrome and Node.js both use an engine called V8, built by Google, which compiles your JavaScript down to fast machine code.

Node.js takes that same V8 engine, but instead of wrapping it in a browser and handing it a document and a window, it wraps it in a program that can run directly on a computer's operating system and hands it a completely different set of abilities: reading and writing files on disk, listening for network connections, and reading environment information about the machine it's running on. So the honest one-line definition is: Node.js = the V8 JavaScript engine + a set of server-side APIs (files, networking, processes) + a system for managing many tasks at once, all packaged so JavaScript can run as a standalone program outside any browser.

Meeting Node for the First Time

Once Node.js is installed on a computer (or available in an online coding environment, which is how you will likely first try it), you get a command called node. Running node --version in a terminal prints the installed version, confirming Node is present. Running just node with no filename opens something called the REPL — short for Read-Eval-Print Loop — an interactive prompt where you type one JavaScript expression at a time and immediately see its result, similar to a calculator. But the far more common way to use Node is to save your code in a file and run that file directly:

// hello.js
console.log("Namaste from Node.js!");
console.log("This script is running on:", process.platform);

Running node hello.js from the terminal prints two lines: the greeting, and then a value like linux or darwin depending on the operating system Node is running on. Notice something important already: console.log still works exactly as it did in the browser — that part is plain JavaScript, unchanged. But process.platform is brand new. process is a special object that only exists in Node; it represents the currently running program itself and gives you information a browser script could never access, because a browser script isn't a standalone operating-system program — it's a guest inside one.

Node's Built-in Toolbox: Modules

Browser JavaScript reaches its extra powers through global objects like window and document that are simply present, everywhere, all the time. Node organizes its extra powers differently: into separate modules that you must explicitly load using a function called require(). This keeps your program lean — you only pull in the machinery you actually need.

Three built-in modules matter most for a first look at Node: fs (file system — reading and writing files), http (creating a web server), and path (working with file and folder paths safely across different operating systems). Here is fs in action, writing a small file and then reading it back:

const fs = require("fs");

fs.writeFileSync("marks.txt", "Aditi,92\nRahul,85\nMeera,78\n");

const data = fs.readFileSync("marks.txt", "utf8");
console.log(data);

Trace this line by line. require("fs") loads Node's file-system module and stores it in the constant fs. fs.writeFileSync creates a file named marks.txt in the same folder and writes three lines of comma-separated text into it, each line ending with \n (a newline character). fs.readFileSync then opens that same file and reads its entire contents as a string, using "utf8" to say "give me readable text, not raw binary bytes." console.log(data) prints exactly what was written: three lines, Aditi's row, Rahul's row, Meera's row. A browser script cannot do this — browsers deliberately block webpages from freely reading and writing files on your computer, for your own security. A Node script, running as a trusted program on the server itself, is allowed to.

Building an Actual Server

Now for the piece that solves the original scoreboard problem: a program that stays running and answers requests from any client that asks. This uses the http module:

const http = require("http");

const server = http.createServer((request, response) => {
  response.writeHead(200, { "Content-Type": "text/plain" });
  response.end("Current score: India 187/4\n");
});

server.listen(3000, () => {
  console.log("Server running at http://localhost:3000/");
});

Read this in order of what actually happens. http.createServer(...) builds a server object, and hands it a function — a callback — that Node will run automatically every single time a request arrives, no matter how many requests that turns out to be. Inside that callback, request represents the incoming ask (which page, which browser, what data it sent) and response represents the reply you get to build and send back. response.writeHead(200, ...) sets the status code — 200 is the standard HTTP code meaning "success, here is your data" — and declares that what follows is plain text. response.end(...) writes the actual reply text and signals "this response is complete, send it now." Finally, server.listen(3000, ...) tells the server to start listening for connections on port 3000 of this machine, and its own callback fires once just to confirm the server has actually started, printing the confirmation message.

Crucially, after server.listen is called, the Node program does not exit. Unlike hello.js earlier, which ran top to bottom and finished, this script keeps running indefinitely, waiting. That is the essential shape of a server: a program that starts once and then stays alive, answering whichever client happens to ask, for as long as it keeps running. Your friend's phone and your laptop can now both send a request to this one running program and both get "India 187/4" back — the shared source of truth your original scoreboard was missing.

How a Request Actually Travels

This diagram shows the full journey of a single request. The browser sends a request into the server's call stack, where your JavaScript callback begins running (step 1). If that callback needs something slow — reading a large file, querying a database, waiting on a network call — it does not freeze and wait right there. Instead, the event loop hands that slow task off to the background (step 2), where Node's underlying system (a library called libuv) handles it using the operating system's own facilities, entirely separately from your JavaScript code. The moment that background work finishes, its result is queued up (step 3), and the event loop picks it up and runs the matching callback on the call stack (step 4), which then finishes building and sending the response (step 5). The single most important fact in this whole diagram is that your JavaScript itself runs in only one place at a time — the call stack is single-threaded — while the slow waiting happens somewhere else entirely, so your one JavaScript thread is never stuck doing nothing.

Why Order of Output Is Not Always Order of Code

This background hand-off has a consequence that surprises every student the first time they see it. Compare two versions of nearly identical code.

// Version A: synchronous (blocking)
console.log("1. Start");
const data = fs.readFileSync("marks.txt", "utf8");
console.log("2. File contents:", data);
console.log("3. End of script");

Version A prints strictly in order: 1, then 2, then 3. readFileSync is synchronous — it blocks, meaning line 2 physically cannot run until the file has finished being read. The whole program waits.

// Version B: asynchronous (non-blocking)
console.log("1. Start");
fs.readFile("marks.txt", "utf8", (err, data) => {
  console.log("3. File contents:", data);
});
console.log("2. End of script (file may still be loading)");

Version B prints 1, then 2, then 3 — the numbers in the code are deliberately out of visual order to make this obvious. fs.readFile (no "Sync") is asynchronous: it starts the file read, immediately hands the slow part to the background as shown in the diagram, and lets the rest of the script continue running without waiting. So "2. End of script" prints before the file has necessarily finished loading. Only once the file read actually completes does Node's event loop go back and run the callback function, printing "3. File contents" last, even though it's written second in the code. This is the core behavior every real Node.js server relies on: while one request's file or database work is happening in the background, the single JavaScript thread is free to start handling the next request, rather than making everyone queue up one at a time.

A useful analogy: a blocking function is a food-stall cook who takes one customer's order, stands and watches the pan the entire time it cooks, and only then serves that one customer before even looking at the next person in line. A non-blocking function is a cook who takes an order, puts it on the stove, and immediately turns to take the next order while the first dish cooks unattended, coming back to plate it the moment it's ready. The second cook serves far more customers per hour using the same one pair of hands — which is exactly why a single-threaded Node.js server can still comfortably handle thousands of simultaneous client requests.

Two Misconceptions Worth Fixing Now

Misconception 1: "Since Node.js is JavaScript, I can use document.getElementById and other browser features inside a Node script." This is false, and it is the single most common error beginners make when moving from browser JavaScript to Node. There is no webpage inside Node, so there is no document and no window object at all — attempting to use either throws a ReferenceError. In exchange, Node gives you objects the browser never had: process, require, module, __dirname (the folder the current file lives in), and __filename (the current file's full path). Browser JavaScript and Node.js JavaScript share the same core language but live in two different environments with two different sets of extra tools, matched to two different jobs: one displays and reacts to a page for a single visitor, the other manages data and requests for everyone.

Misconception 2: "Node.js is multi-threaded, so it can run unlimited pieces of JavaScript at the exact same instant, like a team of independent workers." This overstates what is happening. Your actual JavaScript callbacks — the code you write — run one at a time on a single call stack, in a single thread, exactly as shown in the diagram above. What makes Node fast at handling many clients is not parallel JavaScript execution; it is that the slow, waiting parts (disk access, network calls, timers) are delegated to the operating system and libuv's background thread pool, so your one JavaScript thread is rarely sitting idle. Node achieves high throughput through efficient waiting, not through running your code on multiple threads simultaneously.

Sharing Code with npm

Writing an entire scoreboard, login system, or database connection completely from Node's built-in modules alone would take a long time, so the Node ecosystem includes npm (Node Package Manager), a tool installed automatically alongside Node that downloads and manages code other developers have already published. Every Node project typically has a file called package.json describing the project and listing which external packages it depends on:

{
  "name": "my-scoreboard-app",
  "version": "1.0.0",
  "main": "server.js",
  "dependencies": {
    "express": "^4.18.2"
  }
}

Running npm install express in that project's folder downloads the popular Express library (which simplifies writing servers, compared to using the raw http module by hand) into a folder called node_modules, and records it in package.json. You would then load it exactly like a built-in module — const express = require("express") — except Node knows to look inside node_modules because the name isn't one of its own built-ins. This is also how you would organize and reuse your own code across files. Suppose you save a small helper in one file and use it in another:

// mathUtils.js
function square(n) {
  return n * n;
}
module.exports = { square };

// app.js
const { square } = require("./mathUtils");
console.log(square(6)); // 36

module.exports is how a file declares "here is what other files are allowed to borrow from me" — in this case, just the square function. In app.js, require("./mathUtils") (note the ./, meaning "look in this same folder," unlike require("fs") which needs no path because it's built in) pulls that object in, and destructuring picks out square. Calling square(6) multiplies 6 by itself and returns 36, which prints exactly as commented.

Where This Sits in Your Computer Science Foundation

Client-server communication, the idea that a webpage is a client talking to a distant server, and the request-response cycle are core ideas in the networking and web-technology portions of school Computer Science, and they underpin essentially every real application you use daily — UPI payment confirmations, IRCTC seat checks, exam result portals. Node.js is not itself a syllabus topic you will be tested on by name at this stage, but understanding it concretely — that a server is just a program that keeps running and answers requests, and that JavaScript can be that program — gives you a correct mental model for client-server architecture that is far more solid than memorizing the term alone. It is also the most direct path from "I can write JavaScript for a webpage" to "I can build a complete, working application," since the same language now covers both halves.

Summary

• Browser JavaScript is trapped inside one browser tab and cannot be shared between different users; a server is a separate, always-running program that many clients can talk to, which is what true multi-user, shared-data applications require.
• Node.js is a runtime environment, not a language: it takes the V8 JavaScript engine (also used inside Chrome) and adds server-side abilities like file access and networking, so the same JavaScript syntax can run as a standalone program outside any browser.
• Node organizes its extra powers into modules, loaded with require() — built-in ones like fs (files) and http (servers) need no path; your own files need a relative path like ./mathUtils.
• http.createServer() builds a server whose callback function runs once per incoming request; server.listen(port) starts it listening and keeps the program alive indefinitely.
• Node runs your JavaScript on a single thread and call stack, but hands slow tasks (file reads, network calls) to a background system (libuv), which is why asynchronous functions like fs.readFile can let later code run before their own callback fires — output order is not always code order.
• Node has no document or window (no webpage exists inside it); instead it offers process, require, module, __dirname, and __filename.
• npm installs and manages external packages (like Express) via package.json, letting you reuse code others have published, exactly as module.exports lets you reuse code across your own files.

Check Your Understanding

1. Your classmate says: "Node.js is just JavaScript that runs faster." Explain precisely what is wrong with this statement, using the words "runtime" and "V8" in your correction.
2. Trace the output, in order, of this code, and explain why the order is what it is:

   console.log("A");
   fs.readFile("data.txt", "utf8", (err, data) => {
     console.log("C");
   });
   console.log("B");
   

3. Now rewrite that same code using fs.readFileSync instead, and state what the new output order would be, and why it changes.
4. A friend writes a Node.js script that calls document.querySelector(".score") to try to update a scoreboard, and it crashes. Identify the exact object that is missing and why Node does not provide it.
5. In the request-flow diagram, which single box represents the only place your actual JavaScript callback code executes? Why can that box never run two callbacks at literally the same instant?
6. Given module.exports = { square }; in mathUtils.js, write the one line of code in a different file, app.js, that imports just the square function using a relative path, and show what square(9) would evaluate to.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where node.js: running javascript on the server is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting node.js: running javascript on the server to at least 3 other topics you have studied.