Typed Arrays and ArrayBuffer

The plain-language idea

A normal JS array is a general-purpose, resizable list that can hold anything — numbers, strings, objects, mixed together. That flexibility has a cost: each slot needs bookkeeping about what type it holds.

An ArrayBuffer is the opposite: a fixed-length block of raw bytes, with no idea what's in it. On its own you can't read or write it directly — you need a typed array view (Uint8Array, Int32Array, Float64Array, and others) laid on top, which says "read this buffer as a sequence of 32-bit signed integers" or whatever the type declares. Same memory, different lens.

This is the layer JS uses whenever it talks to something that isn't JS — files, network sockets, WebGL pixel buffers, audio samples, WebAssembly memory.

See it in a real thing: reading binary data from a file

Say you're parsing a small binary file format — a fixed 8-byte header: a 4-byte magic number, then a 4-byte version.

async function readHeader(file) {
  const buffer = await file.arrayBuffer();   // raw bytes, 8 of them
  const view = new DataView(buffer);

  const magic = view.getUint32(0);           // bytes 0-3, as a 32-bit uint
  const version = view.getUint32(4);         // bytes 4-7

  return { magic, version };
}

DataView is a typed-array cousin that lets you read specific byte offsets with an explicit byte order (endianness) — useful for parsed binary formats where fields don't line up neatly on array boundaries.

For uniform data — say, a stream of 16-bit audio samples — a plain typed array view is more direct:

const buffer = await response.arrayBuffer();   // raw PCM audio bytes
const samples = new Int16Array(buffer);        // view it as 16-bit signed ints

samples[0];        // the first sample, as a real number, instantly
samples.length;    // buffer.byteLength / 2 — each Int16 is 2 bytes

No parsing loop, no manual byte-shifting — the view does the interpretation for you, and it's backed by the same memory, not a copy.

What people usually miss

Watch out

• You can't push, splice, or resize a typed array. Its length is fixed at creation, tied to the buffer's byte length. Need to grow it? Allocate a new, larger ArrayBuffer and copy the old data in — there's no automatic resizing like a regular array.
• Typed arrays only hold one numeric type. A Uint8Array clamps or truncates anything you assign — arr[0] = 300 on a Uint8Array (max 255) silently stores 44 (300 mod 256), not an error. Picking the wrong typed array for your data is a real, silent bug source.
• ArrayBuffer itself is opaque. new ArrayBuffer(16) gives you 16 bytes of zeroed memory, but buffer[0] does nothing useful — you must go through a view (Uint8Array, DataView, etc.) to actually read or write it.

The genealogy: the same memory-vs-reference split as everything else

This is the raw-memory version of a distinction you've already met elsewhere: a view and its buffer are two objects pointing at the same underlying storage, the same way two variables can reference the same mutable object. Structured clone and JSON stringification both have to make explicit decisions about how to handle this shared-buffer case, since naively copying a view without its buffer loses the data it's built on.