Node.js is an open-source, cross-platform JavaScript runtime environment that executes JavaScript code outside of a web browser. Built on Chrome's V8 JavaScript engine, Node.js enables developers to use JavaScript for server-side scripting, creating dynamic web page content before the page is sent to the user's browser. This allows for a unified JavaScript development stack for both client-side and server-side applications.
Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. It's widely used for building web servers, REST APIs, real-time chat applications, microservices, and command-line tools.
Before installing Node.js, ensure you have:
Windows users can install Node.js using the official installer from nodejs.org. The installer includes both Node.js and npm (Node Package Manager).
Visit nodejs.org and download the LTS (Long Term Support) version for Windows. The LTS version is recommended for most users as it receives long-term support and is more stable.
Double-click the downloaded .msi file and follow the installation wizard. Accept the license agreement, choose the installation directory (default is C:\Program Files\nodejs\), and ensure "Add to PATH" is checked.
# Check Node.js version
node --version
# Example: v24.x on the supported LTS line
# Check npm version
npm --version
# The npm version depends on the installed Node.js release
# Test Node.js REPL (interactive shell)
node
> console.log('Hello, Node.js!')
Hello, Node.js!
> .exitmacOS users have multiple installation options: the official installer, Homebrew, or nvm (Node Version Manager).
Download the .pkg installer from nodejs.org and run it. Follow the installation wizard similar to Windows.
# Install Homebrew (if not already installed)
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# Install Node.js
brew install node
# Verify installation
node --version
npm --versionLinux users can use a distribution package, a version manager, or an official Node.js binary. Distribution repositories may carry an older supported line, so confirm the installed major against the application support policy.
For production, use a repeatable package or image source, verify its provenance, pin the intended LTS major, and apply security updates through the same deployment process.
# Update package index
sudo apt update
# Install Node.js and npm
sudo apt install nodejs npm
# Verify installation
node --version
npm --version
# If the distribution version is not the required LTS line,
# use an approved version manager, official binary, or container image.# 1. Select the Node 24 LTS archive for your CPU at nodejs.org/download
# 2. Verify the published checksum before extraction
# 3. Extract into a versioned application or tool directory
# 4. Add that versioned bin directory to PATH through system configuration
# 5. Verify the active runtime and package manager
node --version
npm --versionA version manager lets a developer install and switch between Node.js majors without replacing the system runtime. Install the manager from its maintained documentation, review the installer, and pin the project major in its supported version file or engine policy.
# After installing nvm from its maintained documentation:
# Install the latest LTS version
nvm install --lts
# Install and select the course LTS major
nvm install 24
nvm use 24
# List installed versions
nvm list
# Set the default for new shells
nvm alias default 24
# Check current version
nvm currentOnce Node.js is installed, you can create your first program. Node.js can execute JavaScript files and also provides a REPL (Read-Eval-Print Loop) for interactive coding.
// app.js - Your first Node.js program
console.log('Hello, Node.js!');
console.log('Node.js version:', process.version);
console.log('Platform:', process.platform);
// Run this file with: node app.js# Run the JavaScript file
node app.js
# Output:
# Hello, Node.js!
# Node.js version: your installed LTS release
# Platform: linuxOne of the most common uses of Node.js is creating web servers. Here's a simple HTTP server that responds to all requests with "Hello World".
// server.js - Simple HTTP server
const http = require('http');
const hostname = '127.0.0.1';
const port = 3000;
const server = http.createServer((req, res) => {
res.statusCode = 200;
res.setHeader('Content-Type', 'text/plain');
res.end('Hello World from Node.js!\n');
});
server.listen(port, hostname, () => {
console.log(`Server running at http://${hostname}:${port}/`);
});
// Run with: node server.js
// Visit: http://localhost:3000A proper development environment makes Node.js development more efficient and enjoyable. Here are the recommended tools and setup.
VS Code is the most popular editor for Node.js development. Download it from code.visualstudio.com.
# Create a new project directory
mkdir my-node-project
cd my-node-project
# Initialize package.json (interactive)
npm init
# Or use defaults (skip questions)
npm init -y
# Install a package (example: express)
npm install express
# Install dev dependency
npm install --save-dev nodemon
# Run scripts defined in package.json
npm run startThe package.json file is the heart of any Node.js project. It contains metadata about your project and manages dependencies.
{
"name": "my-node-project",
"version": "1.0.0",
"description": "My first Node.js project",
"main": "index.js",
"scripts": {
"start": "node index.js",
"dev": "nodemon index.js",
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": ["nodejs", "tutorial"],
"author": "Your Name",
"license": "MIT",
"dependencies": {
"express": "^4.18.2"
},
"devDependencies": {
"nodemon": "^3.0.1"
}
}| Command | Description |
|---|---|
| node file.js | Execute a JavaScript file |
| node | Start Node.js REPL (interactive shell) |
| node --version | Check Node.js version |
| npm init | Initialize a new Node.js project |
| npm install package | Install a package |
| npm install | Install all dependencies from package.json |
| npm uninstall package | Remove a package |
| npm update | Update all packages |
| npm run script | Run a script defined in package.json |
| npm list | List installed packages |
Install a supported LTS release for production learning and deployment. In July 2026, Node 24 is LTS and Node 26 is Current. Current is useful for testing upcoming behavior, while production applications should normally use an Active or Maintenance LTS line supported by their dependencies and hosting platform.
Use an official installer or a trusted version manager that downloads official binaries. Record the runtime in a version file, package engine policy, container base, and CI configuration so local development and deployment do not drift. Verify with `node --version` and `npm --version` from a fresh terminal.
When upgrading, read the release and deprecation notes, install the new line in isolation, restore dependencies from the lockfile, run tests and a production smoke build, then compare warnings, performance, native addons, and module behavior. Do not upgrade a server by replacing its runtime without an application verification step.
Create a dedicated project folder and initialize `package.json`. Set a clear package name, private flag for non-published applications, supported engine policy, scripts, and an explicit module type. In a `"type": "module"` project, `.js` files use ECMAScript modules; `.cjs` remains CommonJS. Being explicit avoids source-syntax detection surprises and tool disagreement.
Commit the lockfile and install with the project package manager. Put source, tests, configuration validation, and generated output in predictable locations. Ignore dependency directories, secrets, logs, coverage, and build output. A README should list the runtime, package command, environment variables by name, and how to run tests without containing credentials.
Use built-in `node:` specifiers for core modules, such as `node:http` and `node:fs/promises`, so readers can distinguish runtime APIs from packages. Prefer current promise APIs and `async` functions at application boundaries, while preserving error-first callbacks only where an API or integration requires them.
Build the first application with one health-independent route and one deliberate error path. Parse the request target with `URL`, set an explicit status and content type, end every response, and reject unsupported methods. A server that prints "running" is not complete until a request and shutdown have both been verified.
Keep each event-loop callback small. Network I/O is efficient because Node can wait without dedicating one JavaScript thread per connection, but synchronous filesystem work, large JSON parsing, catastrophic regular expressions, or CPU-heavy loops block every client handled by that process. Move sustained CPU work to bounded worker threads or another service.
Handle startup failure, uncaught fatal errors, termination signals, and graceful shutdown. Stop accepting new work, let in-flight requests finish within a deadline, close pools and clients, then exit. Use a process supervisor or orchestrator to restart failures; application code should not pretend an uncertain process can safely continue forever.
Run the service through package scripts rather than relying on a global command remembered by one developer. Keep development conveniences such as watch mode separate from the production start command. A production entry point should load validated configuration, report startup failure clearly, and avoid development-only inspectors or verbose diagnostics.
Verify the application from outside the process: request a known route, send an unsupported method, trigger a controlled error, and terminate it with the same signal used by the deployment platform. Confirm status codes, response media types, log destinations, open-handle cleanup, and the exit code. This small smoke sequence catches lifecycle mistakes that a startup message cannot.
Package only runtime files and production dependencies. Start the packaged artifact in a clean environment with the documented Node version and no undeclared global tools. Record the release identity in diagnostics so an operator can connect a failure to the source, lockfile, and runtime that produced it.
node --version only proves the runtime is installed and available on PATH. npm install also depends on npm itself, network access, registry configuration, permissions, package.json, lockfile health, and sometimes native build tools. If install fails, read the first npm error instead of reinstalling Node immediately.
Different projects often require different Node major versions. nvm lets you switch versions per shell or project instead of constantly replacing the system installation. That prevents a new tutorial project from breaking an older app that still depends on another runtime.
Run node --version, npm --version, and node your-file.js in the same terminal VS Code uses. Many setup problems come from PATH differences between PowerShell, Command Prompt, Git Bash, and an editor terminal.
Explore 500+ free tutorials across 20+ languages and frameworks.