Why a Buffer's bytes live outside the garbage collector — and how that lets the kernel hold a pointer.

JavaScript grew up in the browser. Its only sequence-of-data type was the UTF-16 string, and every object lives on V8's garbage-collected heap — a moving, compacting collector that relocates live objects to defragment. The address of a normal JS object is therefore not stable across a GC cycle.

The operating system is the opposite. read(2) wants a pointer and a length and writes bytes there. write(2) wants a stable pointer it can hand to the NIC or disk controller. Bytes are bytes — no encoding, no UTF-16.

A server runtime must live in both worlds simultaneously, and that creates three hard constraints. Every API in this volume answers some part of them.

These three are the ECMAScript primitives Node inherits, and they already encode the copy-vs-view distinction that recurs everywhere later. An ArrayBuffer is a fixed-length region of raw bytes — deliberately opaque, you cannot index it. The V8 detail that matters: the small wrapper object sits on the GC heap, but the backing store — the actual bytes — is allocated off-heap with a stable address. V8 tracks it as external memory for collection pressure, but never moves or scans the payload. That stable backing store is exactly what makes ArrayBuffer the foundation for talking to the kernel.

Buffer's sprawl of numeric accessors looks intimidating until you see the pattern that generates it: {read | write} × {UInt | Int | Float | Double | BigInt} × width × {BE | LE}. Pick a method, pick an offset, and you are doing exactly what a C struct parser does — choose offset, width, signedness, byte order, then twiddle. Below is a live 8-byte buffer wrapped by a real DataView. Change the lens and watch which bytes are consumed and what value falls out. The bytes never change; only the reading does.

When V8 shipped real typed arrays, Node rebased Buffer to be a subclass of Uint8Array — the single most clarifying fact about it. Everything from the standard layer applies; the extra methods are a struct-packing toolkit and a set of encodings. The three allocators are points on one curve. Click the buttons to allocate into a real 8 KiB pool and watch where the bytes land.

The copy-vs-view fork bites here too, and it is inconsistent by design. Tap each to see what actually happens to the memory.

fs.open() returns an integer file descriptor — the same fd from open(2). fs.read(fd, buffer, offset, length, position) maps almost 1:1 onto pread(2): you supply the Buffer, the kernel fills length bytes at position into your buffer at offset. There is essentially no abstraction tax — you are handing the kernel your stable off-heap pointer. The encoding, if any, is a post-processing step applied to bytes that were always read as binary.

Sockets sit directly on the epoll/kqueue/IOCP readiness loop — the OS tells libuv when a fd is ready, and the work is genuinely async. Regular files can't be polled, so file reads, DNS lookups, and CPU-bound crypto/zlib are dispatched to the 4-thread worker pool, where they block on a real thread until done. Fire the operations below and watch the path each one takes. Queue five file reads and you will see the fifth wait for a free thread.

Streams are the abstraction over "data arrives in chunks over time," and by default those chunks are Buffers. The first-principles concept is backpressure. writable.write(chunk) returns false when the internal queue exceeds highWaterMark; the 'drain' event says resume. It is flow control in the same spirit as TCP's receive window — stopping a fast producer from exhausting memory against a slow sink. Drag the consumer speed and watch write() flip to false.

node:net is TCP riding uv_tcp_t on the readiness loop, and its crucial property is that TCP is a byte stream with no message boundaries. A 'data' event delivers whatever bytes happened to be available — maybe half a logical message, maybe three glued together. The Buffer chunks have no relationship to your protocol's framing. Toggle the two sends below to see them arrive split, then merged.

UTF-8 code points are 1–4 bytes. When a binary stream is split at arbitrary points — TCP packet boundaries, fs read sizes — a chunk boundary can fall inside a multi-byte sequence. Decode each chunk independently with chunk.toString('utf8') and both seams emit the replacement character �, corrupting the character. (Volume I traces this byte-by-byte for "café €99".) The fix is one function with memory: decoder.write() holds back any incomplete trailing sequence and carries it to the next call; decoder.end() flushes.

Both modules hand your Buffer's stable pointer almost directly to a compiled C library — OpenSSL for crypto, zlib/brotli for compression. They operate on Buffers because letting UTF-16 or an ambiguous encoding touch key material or hash input is how you get subtle, dangerous bugs: the same input must always mean the same bytes. Each card opens the gotcha that bites people.

This is the bottom of the stack, and it makes the whole "where do the bytes live" theme explicit. The interesting calls are the external variants: napi_create_external_buffer wraps memory you already have — a pointer from mmap, a shared-memory segment, a frame from a hardware device — and exposes it to JS as a Buffer without copying a byte. You provide a finalizer so that when the JS wrapper is garbage collected, your C code frees the underlying memory. That finalizer is how two ownership models — GC and manual free — are reconciled across the seam.