What Node JS is and how it works

Node JS is an open source runtime that executes JavaScript outside the web browser. It pairs Google's V8 engine, which compiles and runs the language, with a layer of C and C++ libraries that give a script access to files, sockets, processes, timers, and cryptography. That pairing is the whole idea: Node JS takes a language built for page interactivity and turns it into a general purpose tool for writing servers, command line programs, build pipelines, and background workers.

The design decision that shapes everything else is the event loop. Rather than dedicating an operating system thread to each connection, Node JS runs your JavaScript on one thread and hands slow work such as disk reads and network requests to the system underneath, collecting the results later. A single Node JS process can hold thousands of mostly idle connections without paying for thousands of call stacks, which is why the runtime became popular for APIs, proxies, and anything that spends its life waiting on other services.

Node JS first appeared in 2009 and is now developed in the open by a large contributor base under the OpenJS Foundation, on a published release calendar with long term support windows. Growing beside it was npm, the bundled package client and registry that turned third party code into a one line install. Most Node JS projects today are a small amount of application code sitting on a deliberately chosen set of dependencies.

This page covers the origins of the project, the mechanics of the loop and the thread pool, the two module systems, the core library, the ways to use more than one CPU core, the release calendar, and the practical work of running Node JS in production. Code samples are described rather than dumped, so the concepts stay portable across versions.

[01]Origins and stewardship

Ryan Dahl introduced Node JS at JSConf EU in Berlin in November 2009, after a first release earlier that year. His argument was that most server frameworks of the era blocked on input and output by default, and that programmers therefore paid for concurrency in threads and locks. JavaScript, with its callbacks and its lack of an existing blocking I/O library, was an unusually clean host for an event driven model, and V8 was fast enough to make the idea practical.

A runtime is only as useful as the code you can reach from it. In 2010 Isaac Schlueter released npm, which gave Node JS a manifest format, a dependency resolver, and a public registry. Publishing became trivial, module boundaries stayed small, and the ecosystem grew faster than any single vendor could have planned. That growth is the reason people still reach for Node JS on projects that have nothing to do with web servers.

In late 2014 a group of contributors forked the project as io.js, frustrated with the pace of releases and with a governance model controlled by a single company. The fork shipped faster and pulled contributors with it, and the dispute ended in a merger: the code came back together in 2015 as version 4.0 under the newly formed Node.js Foundation, hosted by the Linux Foundation, with an open technical steering committee. Nearly every governance feature people now rely on, including the release calendar, dates from that reconciliation.

In 2019 the Node.js Foundation merged with the JS Foundation to create the OpenJS Foundation, which remains the home of the project. Day to day work is split among working groups covering releases, security, build infrastructure, diagnostics, and documentation, and any change large enough to affect users goes through public discussion. For a team betting a product on Node JS, that visible process matters as much as any benchmark, because it makes the support timeline predictable.

The project also left marks outside its own repository. libuv, the cross platform asynchronous I/O library written for Node JS, is now used by unrelated language runtimes, and the design of the module and package ecosystem influenced later JavaScript tooling. A general history of the project and its releases is maintained on Wikipedia for readers who want the chronology in one place.

[02]Architecture of the runtime

It helps to picture Node JS as three layers stacked on each other. At the bottom sits V8, which parses your JavaScript, compiles it to machine code, and manages the heap. Beside V8 sits libuv, which owns the event loop, the platform specific polling mechanisms, and a small thread pool. On top of both sits the part written in JavaScript: the core modules you import, implemented against C++ bindings that expose the lower layers.

What the loop actually does

The loop is a repeating sequence of phases, not a vague queue. Each turn moves through expired timers, pending system callbacks, the poll phase where the process waits for I/O events, the check phase where setImmediate callbacks run, and finally close callbacks for sockets and handles that have been torn down. Understanding the order explains most of the surprising scheduling questions people ask about Node JS.

• >timers run callbacks scheduled by setTimeout and setInterval whose delay has elapsed.
• >poll is where the process blocks, waiting for readable sockets, finished file operations, and other completions.
• >check runs setImmediate callbacks, which is the correct way to yield to the loop between chunks of work.
• >close handles cleanup callbacks after a handle is destroyed.

Two queues sit outside the phases and drain between them. Callbacks registered with process.nextTick run first, then the microtask queue that resolves promises. Because both drain completely before the loop advances, a recursive stream of ticks or promise resolutions can starve timers and I/O entirely, which is one of the few genuinely counterintuitive traps in Node JS.

The thread pool nobody notices

Node JS is often called single threaded, which is true of your JavaScript and false of the process. libuv keeps a pool, four threads by default and adjustable with the UV_THREADPOOL_SIZE environment variable, that carries out work the operating system cannot do asynchronously in a portable way. File system calls, DNS lookups through dns.lookup, compression, and several cryptographic operations all go there.

The practical consequence is that a workload heavy in file reads or password hashing can exhaust the pool while sockets sit idle, producing latency that looks like a network problem. Raising the pool size or moving the work elsewhere fixes it. Network I/O, by contrast, does not use the pool at all, so a Node JS proxy handling many connections stays cheap.

Memory is managed by V8's garbage collector, with a bounded old space whose default depends on the platform and available RAM. Long lived Node JS services usually fail not from raw allocation speed but from retention: caches without eviction, listeners never removed, closures holding request bodies. The heap flag --max-old-space-size raises the ceiling, but it postpones a leak rather than curing one.

Asynchronous style has moved on considerably since the early years. Callbacks with an error first argument were the original convention, promises standardized composition, and async functions with await made asynchronous code read top to bottom. Modern Node JS core exposes promise flavored versions of most APIs, and util.promisify covers older interfaces you cannot change.

[04]Modules and packages

Node JS predates standardized JavaScript modules, so it invented its own. CommonJS loads a file synchronously with require and exposes values by assigning to module.exports. Resolution walks up the directory tree through node_modules folders, caches each module after first load, and treats the file system as the namespace. Millions of published packages still ship this way.

ECMAScript modules are now the standard alternative and are fully supported. A package opts in with "type": "module" in its manifest, or a single file opts in with the .mjs extension, while .cjs forces the older format. ESM in Node JS is asynchronous, statically analyzable, and supports top level await. Recent releases also allow require of a module graph that has no top level await, which removed the sharpest edge of the transition.

Built in modules can be imported with the node: prefix, as in node:fs or node:path. The prefix is worth adopting everywhere: it makes the intent unambiguous to readers and tooling, and it cannot be shadowed by a package of the same name, which closes a small but real class of confusion attacks against Node JS projects.

Dependencies and the manifest

Every Node JS project is described by package.json: its name and version, its entry points, its scripts, and its dependency ranges expressed in semantic versioning. Installing writes a lockfile that pins the exact resolved tree so that a colleague, a CI runner, and a production image all get identical bytes. npm ships with Node JS, and pnpm and Yarn are drop in alternatives that reshape how packages are stored on disk.

Dependency discipline is the single highest leverage habit in Node JS work. Prefer fewer and larger dependencies from maintained sources, read what a package pulls in transitively before adding it, commit the lockfile, run audits as part of the pipeline, and keep install scripts under review since they execute code on your machine. The registry's openness is why the ecosystem is so productive and also why the supply chain deserves attention.

[05]The core library

A surprising amount of work needs no dependencies at all, because Node JS ships a broad standard library. There is file system access, path manipulation, HTTP and HTTPS clients and servers, raw TCP and UDP sockets, URL parsing, cryptography, compression, operating system information, process spawning, an event emitter, streams, binary buffers, worker threads, a test runner, and diagnostic hooks. Learning the core well reduces both your install size and your exposure.

Streams are the most characteristic part of the library and the least understood. A readable stream produces chunks, a writable stream consumes them, a transform sits between the two, and pipeline wires them together with proper error propagation and cleanup. The point is backpressure: a slow consumer tells a fast producer to pause, so a Node JS process can move a file larger than its own memory without buffering the whole thing.

The HTTP module is deliberately low level. It gives you request and response objects, keep alive handling, and headers, and it leaves routing, body parsing, and content negotiation to you. Most teams put a framework on top for ergonomics, and that is a reasonable default, but reading the raw server API once pays off when you need to debug a timeout, a header limit, or a hung connection in a live Node JS service.

Over recent years the core has absorbed a series of web platform standards, so code moves more easily between browsers and servers. Global fetch, URL, AbortController, structuredClone, Web Streams, and the standard timers promises API are all available. For newer Node JS projects, the browser flavored spelling of an operation is often the right one to reach for.

Tooling has moved inward too. The built in test runner in node:test covers describing suites, assertions, mocking, watch mode, and coverage reporting well enough for many codebases; node --watch restarts a process when files change; and an inspector protocol connects the same debugger and profiler used for browser JavaScript. A modern Node JS setup can be considerably smaller than one assembled five years ago.

[06]Using more than one core

The event loop makes I/O cheap and does nothing for computation. If a request spends its time parsing a large payload, resizing an image, or running a simulation, a single Node JS process will saturate one core while the rest of the machine idles. There are three established answers, and choosing between them is mostly about how much state needs to be shared.

Worker threads, from node:worker_threads, run separate JavaScript environments inside the same process, each with its own loop and heap. They communicate by message passing, and they can share raw memory through SharedArrayBuffer when a copy is too expensive. This is the right tool for CPU bound tasks inside an otherwise responsive Node JS server, ideally with a small pool of long lived workers rather than one thread per job.

The cluster module and plain child processes take the other route: several operating system processes, each isolated, with incoming connections distributed among them. Isolation is the advantage, since one crashed worker does not take the others down, and the cost is that nothing is shared except through sockets or external stores. Many production Node JS deployments run one process per core this way and keep the code inside each process blissfully single threaded.

The third answer is to scale outward. Because a Node JS process is small and starts quickly, running many replicas behind a load balancer is often simpler than orchestrating threads, and it matches how containers and serverless platforms already work. Whichever route you take, keep session state out of process memory so that any instance can serve any request.

[07]Release lines and versions

Node JS ships a new major version every six months, in April and in October. Even numbered majors are the ones that matter for most users: after six months as the Current line, an even major becomes a long term support release in October of the year it appeared. Odd numbered majors never become LTS and exist to give experimental work a real audience before it lands somewhere permanent.

Once a line enters long term support it gets twelve months as Active LTS, where backports are generous, and then a further eighteen months of maintenance limited to serious bug fixes, security patches, and documentation. That gives thirty months of support from the LTS date, or three years from the original release. The table below traces the recent even numbered lines of Node JS.

The practical guidance is short. Run the most recent Active LTS line in production, keep patch updates flowing continuously, and plan the jump to the next LTS line while the current one is still in maintenance rather than after it expires. Try the Current line in development if a new capability interests you, but do not let an unsupported Node JS version become the foundation of a service you have to keep alive.

[09]Node JS and the alternatives

Server side JavaScript is no longer a single runtime. Deno, from the original author of Node JS, was released in 2020 with permissions off by default and TypeScript support built in. Bun arrived at version 1.0 in 2023 on a different engine, JavaScriptCore, with speed and an all in one toolchain as its pitch. Both are compatible with much of the npm ecosystem, and both borrow ideas that Node JS has since absorbed in its own way.

Against thread per request platforms such as typical JVM or Python setups, the trade is legibility for isolation. Those stacks let a developer write straight line blocking code and let the scheduler sort out concurrency, at the cost of memory per thread and synchronization bugs. Node JS makes concurrency explicit in the syntax, which suits I/O heavy services and punishes accidental computation on the hot path.

For most teams the deciding factors are not benchmarks. They are the size of the ecosystem, the number of engineers who already know the language, the availability of hosting and observability tooling, and the length of the support window. On all four, Node JS remains the conservative choice, and the newer runtimes are worth watching and worth prototyping with.

[10]Where Node JS fits and where it does not

The runtime is at its best when a program's job is to move data between other systems. Teams at large consumer platforms including Netflix, LinkedIn, and PayPal have published accounts of running Node JS in front of their existing services, and the pattern is consistent: a thin, fast layer that aggregates and shapes responses rather than performing heavy computation itself.

• >HTTP and GraphQL APIs, gateways, and backend for frontend layers that fan out to internal services.
• >Real time features over WebSockets or server sent events, including chat, presence, and live dashboards.
• >Server rendered and hybrid web applications, where the same language runs on both sides of the wire.
• >Command line tools, code generators, and automation scripts distributed through the registry.
• >Streaming pipelines and queue consumers that transform records as they pass through.

Front end tooling deserves its own mention, because it is where almost every JavaScript developer meets the runtime first. Bundlers, linters, formatters, type checkers, test runners, and package scripts all execute on Node JS, which means even a team writing exclusively browser code depends on the version installed on their machines and in CI.

Real time work suits the model particularly well. Thousands of open sockets with occasional small messages is exactly the shape of load an event loop handles cheaply, and holding a connection open in Node JS costs a handle and a little memory rather than a thread. The constraint shows up elsewhere, in coordinating state across replicas, which is a distributed systems problem rather than a runtime one.

The weak spots are predictable. Sustained numeric computation, large scale image or video processing, and workloads needing precise memory control fit poorly, since a garbage collected single loop is the wrong instrument. Long batch jobs that saturate a core are better off in a dedicated worker or another language. Node JS can call out to native addons or spawn a specialized binary, which is often the pragmatic middle path.

None of this makes the choice binary. Plenty of healthy architectures put Node JS at the edge, where request shaping and streaming happen, and keep the compute intensive core in whatever language suits it, with a queue or an RPC boundary between them.

[12]Security practices

Security in Node JS splits into two halves: the code you wrote and the code you installed. Your own half is the familiar list, namely validating input at the boundary, using parameterized queries, escaping output, keeping secrets in the environment, setting sensible request size and timeout limits, and never passing user input into a shell command.

The installed half is where the ecosystem's openness cuts both ways. Audit dependencies regularly, pin them with a lockfile, review the diff when a package updates itself in unexpected ways, prefer packages with narrow scope and active maintenance, and be wary of lifecycle scripts that run on install. A compromised transitive dependency has the same access to your process as your own modules do.

Node JS has also grown a permission model that restricts what a process may do at the runtime level, limiting file system reads and writes, child process creation, and native addon loading by command line flag. Combined with running as an unprivileged user and with a read only file system where possible, it narrows the damage a hostile package or an injection bug can cause.

Finally, patch promptly. The project publishes security releases across all supported lines, usually with an advance notice, and staying on a supported Node JS version is what makes those fixes available to you at all. An end of life runtime accumulates unpatched vulnerabilities silently, which is the most common way an otherwise careful deployment ends up exposed.

[14]Frequently asked questions

Most questions about Node JS performance turn out to be questions about what else is holding the loop.