JavaScript usually works with high-level values such as strings and regular arrays, but binary data is ultimately stored as bytes. An ArrayBuffer provides a fixed-size block of raw binary memory, such as `new ArrayBuffer(8)`, which allocates 8 bytes. By itself, however, an ArrayBuffer does not provide convenient methods for interpreting or modifying those bytes.
Typed arrays and DataView act as views over an ArrayBuffer. A typed array interprets a region of memory as a sequence of one numeric type. For example, a `Uint8Array` uses one byte per element, while `Uint16Array`, `Uint32Array`, and `BigUint64Array` use 2, 4, and 8 bytes per element respectively. Multiple views, including typed arrays with different element types, can share the same buffer and see changes made through overlapping byte ranges.
DataView is useful when a buffer contains fields of different types at specific offsets. For example, a binary protocol might define byte 0 as a message type, bytes 1–2 as a length, and bytes 3–6 as a user ID. A DataView can read those fields with methods such as `getUint8`, `getUint16`, and `getUint32`.
This seems especially relevant to network protocols. TCP preserves byte order but does not preserve the boundaries of the chunks sent by the application, so code must collect incoming data until it has enough bytes to parse a complete message. Once the message is complete, DataView or a typed array can interpret it according to the protocol.
My current understanding is that a typed array is best when the data is a uniform sequence of one numeric type, while DataView is better for mixed fields, arbitrary byte offsets, and explicit control over endianness. DataView methods default to big-endian unless the little-endian argument is set to `true`. Typed arrays use the platform's native byte order. Are there any other technical corrections or important details worth adding?
2 Answers
The main distinction is correct. One important detail is that a typed array is not exclusive to one buffer. You can create both a `Uint8Array` and a `Uint32Array` over the same `ArrayBuffer`; they share the underlying memory, so changes to overlapping bytes are visible through both views. DataView is the better choice when a binary layout mixes field sizes or requires arbitrary offsets.
Endianness is an important addition to the protocol example. `DataView` methods such as `getUint16` and `setUint16` use big-endian order by default. If the format is little-endian, pass `true`, for example `view.getUint16(1, true)`. Typed arrays generally use the platform's native byte order, so DataView is preferable when the byte order must be specified explicitly.
Good point. I left endianness out initially to keep the explanation simpler, but it matters whenever the sender and receiver follow a defined binary format.
That makes sense. I was thinking of a typed array as having one interpretation per view, but multiple views can absolutely use the same underlying buffer.