Skip to content

SYSTEM Cited by 3 sources

Node.js

Node.js (nodejs.org) is the server-side JavaScript runtime built on Google's V8, originally released 2009. Outside the browser, it is the default runtime for JS/TS server workloads — API services, SSR, build tooling, CLI utilities.

Node.js ships both its own streaming API (stream.Readable / stream.Writable / stream.Transform, predating the web platform's) and the WHATWG Web Streams API (adopted post-v15 via Readable.toWeb / Writable.toWeb). Two parallel streaming stacks coexist; most older Node code uses Node streams, newer frameworks targeting cross-runtime portability use Web streams. The interface between them is the stream-adapter overhead surface.

Governance

  • Technical Steering Committee (TSC) — open-source project governance; James Snell (Cloudflare Workers engineer) + Matteo Collina (Platformatic CTO) + Robert Nagy are TSC members / contributors cited in Cloudflare's 2026-02-27 streams critique.
  • OpenJS Foundation-hosted; permissive (MIT + BSD) licensing across core modules.

Relevance to streaming performance

Two independent 2025-2026 Cloudflare posts converge on Node.js streaming as a performance pain point:

Node.js has not yet invested significant effort in optimizing its Web streams implementation; Vercel's proposed "fast-webstreams" work promises ~10× gains by eliminating promises on certain code paths. Cited in the 2026-02 post: "as one of the core maintainers of Node.js, I am looking forward to helping Malte and the folks at Vercel get their proposed improvements landed!"

undici — Node's fetch implementation

Node.js's built-in fetch() uses undici, a first-party HTTP/1.1 + HTTP/2 client. Unconsumed fetch() response bodies (where code only checks response.ok and never reads / cancels the body stream) have caused connection-pool exhaustion under load — a real production bug fixed in undici. The 2026-02 article cites this as a canonical example of how the Web streams spec's complexity "makes dealing with these types of issues [not] easy", even when the immediate fault is an implementation bug.

Workers vs Node.js

Cloudflare Workers and Node.js both embed V8 but make different architectural choices:

Axis Node.js Workers
Isolation Process-level V8 isolate (128 MB default)
Concurrency One event loop per process One isolate per request / reused across requests
I/O libuv + Node bindings Runtime-provided ABIs (KV, D1, DO, R2)
Streaming Node streams + Web streams Web streams-first (Node-streams absent by default)
Billing model Wall-clock cost CPU time (not wall-clock)

Workers targeting Node.js compatibility expose nodejs_compat to run unmodified Node libraries; Cloudflare's 2026-01-29 Moltworker case study measured that 15 of the top 1 000 NPM packages fail natively on Workers after excluding build/CLI/browser-only — a 98.5 % compatibility rate for production libraries.

Seen in

Last updated · 200 distilled / 1,178 read