Skip to content

SYSTEM Cited by 7 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!"

2026-04-21 update: fast-webstreams ships; PR #61807 merges

The fast-webstreams work is now real (sources/2026-04-21-vercel-we-ralph-wiggumed-webstreams-to-make-them-10x-faster): library on npm as experimental-fast-webstreams, passing 1,100/1,116 WPT; two ideas landed upstream via Node.js TSC member Matteo Collina's PR nodejs/node#61807 — "stream: add fast paths for webstreams read and pipeTo":

  1. read() fast path — buffered reads return pre-resolved Promises directly without allocating ReadableStreamDefaultReadRequest. See synchronous-fast-path-streaming.
  2. pipeTo() batch reads — drain multiple reads from the controller queue without per-chunk request objects; backpressure preserved via desiredSize check after each write.

Measured: ~17-20 % buffered-read improvement; ~11 % pipeTo improvement. Applies to every Node.js user free. Canonical instance of patterns/upstream-contribution-parallel-to-in-house-integration at the streaming-runtime altitude: library + upstream PR in parallel.

James Snell's tracking issue nodejs/performance#134 enumerates remaining opportunities (C++-level piping for internally-sourced streams, lazy buffering, WritableStream adapter double-buffer elimination).

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.

node:net / node:fs compat as a Wasm syscall bridge (2026-09-28)

A recurring Cloudflare pattern reuses the Node.js compatibility API surface as a ready-made syscall bridge for Wasm workloads, rather than building custom bridging APIs on either side. In the 2026-09-28 native-Rust-on-Workers work, the last unsupported piece of Tokio on the Emscripten target was the net feature (TCP/UDP/Unix sockets) — Emscripten had poll() + a WebSocket emulation layer but not epoll_wait(). Emscripten already had -sNODERAWFS to forward filesystem calls into Node's FS APIs; Cloudflare added the socket counterpart -sNODERAWSOCKETS (40+ PRs) built on the node:net API. The leverage: "because Workers implements the same node:net API", the identical Emscripten backend that works in Node.js works on Workers with no custom APIs on either side — epoll + TCP + UDP + Unix sockets. The FS side (node:fs under -sNODERAWFS) is what lets a native Rust server's std::fs calls land on a swappable JS-backed filesystem (in the Pumpkin demo, a SQLite-backed Durable Object FS). Node's compat surface is thus doing double duty as the portable POSIX-emulation target two runtimes agree on. (Source: sources/2026-09-28-cloudflare-supporting-native-rust-in-workers-with-the-new-emscripten-target)

Seen in

  • systems/v8-javascript-engine — the JS engine Node.js embeds.
  • systems/web-streams-api — the WHATWG streaming API Node adopted alongside its own stream module.
  • systems/new-streams — Snell's POC alternative streaming API, Node.js-compatible.
  • systems/cloudflare-workers — the sibling V8-isolate runtime that shares V8 with Node but diverges on I/O / billing / concurrency.
  • systems/opennext — the Next.js adapter layer whose Node-stream-layer fixes ship upstream to Node.
  • promise-allocation-overhead — the dominant cost in Node's current Web streams implementation.
  • stream-adapter-overhead — the Node ⇆ Web cost surface.
  • systems/bun — alternative JS runtime now available alongside Node.js on Vercel Functions; 28 % TTLB win on CPU-bound Next.js SSR per 2026-04-21 Vercel profiling.
  • systems/vercel-functions — the multi-runtime function platform exposing Node.js + Bun via config-axis selection.
  • web-streams-as-ssr-bottleneck — the profiling finding Vercel + Cloudflare both disclosed at Node's Web-Streams layer.
  • runtime-choice-per-workload — the four-axis trade-off Node.js sits on.
  • multi-runtime-function-platform — the platform-design pattern Vercel operationalises with Node.js
  • Bun.
  • systems/fast-webstreams — userland reimplementation of the Web Streams API on top of Node's stream.* internals; upstream source for PR #61807.
  • systems/react-flight — React's byte-stream serialiser — dominant production workload Node's Web Streams implementation must serve.
  • synchronous-fast-path-streaming — the specific optimisation landed in Node PR #61807.
  • microtask-hop-cost — unavoidable scheduling cost the fast path cannot remove.
  • patterns/upstream-contribution-parallel-to-in-house-integration — the library + upstream-PR model for rolling out streaming improvements.
Last updated · 766 distilled / 2,225 read