Concepts

ArrayBuffers represents a byte-array in physical memory. An ArrayBuffer is the actual storage for the bytes but is rarely used directly - in fact, you don't have access to read content of ArrayBuffer directly and can only pass a reference for it. They are on the other hand used for binary data transfers between server and client, or from the user's file system via Blobs.

^{ArrayBuffer byte array in memory - each index equals one byte. ArrayBuffer is aligned in memory.}

To read the content of an ArrayBuffer you need to use a view. This sits on top and offers an "api" to access the bytes by different width types, or arbitrarily.

Width-dependent Views

The different views are used depending on what you need. If you only need to read byte values, ie. signed values between -128 and 127 -or- unsigned values between 0-255, you would use Int8Array or Uint8Array. Notice that their names are a bit "misleading" as they are views and not arrays, and only references the underlying ArrayBuffer.

Likewise, you have views for Int8Array, Uint8Array, Uint8ClampedArray, Int16Array, Uint16Array, Int32Array, Uint32Array, Float32Array and Float64Array.

With the exception of *int8Arrays the others come with some requirement to ArrayBuffer size. For example, a Uint32Array view must sit on top of an ArrayBuffer that is divisible by four, otherwise it throws an error. *int 16 views would require a two-byte boundary.

This is usually not a problem because you can specify number of indexes using the view's constructor directly and a matching ArrayBuffer will be created automatically for it fulfilling these requirements.

And since the ArrayBuffer is a byte-array a *int16 view reads two bytes from it - or, one index = two bytes, *int32 four, or one index = four bytes, and so on.

The main difference between Uint8Array and Uint8ClampedArray is that values outside the range are subject to modulo (for example 256 becomes 0) with the ordinary arrays. In the clamped array the values are as suggested clamped instead (256 becomes 255).

^{Int16/Uint16 views - each index represents two bytes and is memory aligned.}

^{Int32/Uint32 and Float32 views - each index represents four bytes and is memory aligned.}

^{Float64 view - each index represents eight bytes and is memory aligned.}

DataView for flexibility

Then there is the DataView. This is intended for scenarios where you need a flexible ArrayBuffer and need to read variable widths and from positions in the buffer that is not necessarily width or memory aligned.

For example, a *int32 index will always point to a memory location that is dividable by four. A DataView on the other hand can read a Uint32 from say, position 5 and will take care of all the needed steps internally (bit shifting, masking etc.), but at the cost of a tiny overhead.

One other difference is that a DataView doesn't use indexes but absolute byte-positions for the data it represents, and it comes with its own methods to read or write various widths from/to any position.

^{DataView - can read from any position and any width.}

In other cases you can use several different views referencing the same underlying ArrayBuffer.

There is currently not 64-bits views for integer numbers, but seem to be proposed for ES8.

SharedArrayBuffers

It's also useful to mention the new SharedArrayBuffers that can be used across web workers.

You could (and still can) use transferable objects in the past in some browsers, but SharedArrayBuffers is more efficient in the sense the memory stays the same, only information about it is transferred. SharedArrayBuffers cannot become detached as ArrayBuffers can.

Purpose and Usage areas

Typed arrays are good to store specific numeric values and are fast. Bitmaps is a typical candidate for typed arrays (e.g. canvas 2D/WebGL).

Heavy data processing of data inside web workers is another use and so on. I already mentioned binary transfer between client and server or the file-system.

DataViews are perfect to parse or build binary files and file formats.

Typed arrays are an excellent way to pack binary data for sending over the net, to server or via web sockets and things like data-channels for WebRTC.

If you deal with audio, video, canvas, or media recording, there is often no way around using typed arrays.

The keys for using typed arrays are performance and memory. They are most often used in special scenarios, but there is nothing wrong using them in ordinary cases when you only need to store numeric values (or utf-8 strings, encryption vectors etc.). They are fast and have a low memory footprint.

Precautions

There are a couple of precautions to be aware of:

Byte-order

Some precautions must be made in regards to byte-order. Typed arrays always reflects the CPU-architecture they run under, ie. little-endian or big-endian. Most consumer systems are little-endian but when using *int16 and *int32 arrays you must pay special attention to byte-order. DataView can help with this part too, but is not always a good choice if performance is important.

Byte-order is also important when receiving data from server. They are usually always in big-endian format (AKA "network order"). For parsing file formats the same will apply.

Floating Point Number Encoding

Float32/Float64 will read and write numbers encoded in the IEEE-754 format. This is also something to be aware of if several views are used for the same buffer.

Cross-browser Support

Most browsers supports typed arrays nowadays. If you have to deal with older browsers you have to go back to IE9 or older mobile browsers to not be able to use them.

Safari is not particular optimized in regards to their performance, but the other benefits are there. Version 5.1 does not support Float64.

Mobile devices has their own hardware limitations, but in general: typed arrays are safe to use. For special cases there exist a polyfill.

An ArrayBuffer is more than just a simple array. It contains raw binary data. This is very useful for direct memory manipulation and conserving space.

When you create a normal array, you won't get a proper set of contiguous memory in many cases since arrays can contain any combination of different kinds of objects. This is useful when you have dynamic data and multiple types together (frequently happens in JS) but is not so useful when you know the exact layout of memory that you need.

This also allows you to view the data at the byte level. For example, it's pretty common in binary data formats to have a n byte long identifier number, an m byte long field telling you how many bytes are used for this field, and m' bytes of data that actually makes up the data field.

[ identifier ][ bytes of data ][ data ]

With an ArrayBuffer, you have the option of moving through that data on the byte level by using various Views. A regular array doesn't allow you to move through the data with that level of granularity because no guarantees are made about the memory layout.

Finally, because you are telling the compiler/interpreter exactly how much space you're going to use and exactly how you're going to view it, it can do much more advanced optimizations when working with that data. When iterating through that data, it doesn't have to make calculated leaps through memory. Instead, it knows exactly how far to move ahead in memory to find the next data point.

As for what Uint8Array is, it's a typed array. Essentially, it tells the compiler/interpreter that you will be accessing this data exclusively as 8-bit uints which, again, allows it to make better optimizations. Then you can use standard array indexing on it (arr[0], arr[1], etc.) and you'll be getting back the equivalent uint values out of the array.

TL;DR They take less space when the exact data format is known, allows you to move more exactly through your data and gives the compiler/interpreter greater options for optimization.

Uint8Array is a general-purpose byte-array that’s available in both nodejs and browsers. Buffer is a subclass of Uint8Array that’s only available in Node.js (for historical reasons). both are primarily used for manipulating binary (byte) data.

historically, when Node.js first came about, general-purpose Uint8Arrays didn’t exist, so it had to invent its own “Buffer” type for handling binary-data. after general-purpose Uint8Arrays were introduced with ES6, Node.js (after version 4.0) decided to migrate Buffer over from a separate data-type -> subclass of Uint8Array (to try and make it more browser-compatible with Uint8Array).

https://www.quora.com/What-is-the-relationship-between-a-Buffer-and-an-Uint8Array-in-Node-js