Instances of Buffer are also instances of Uint8Array in node.js 4.x and higher. Thus, the most efficient solution is to access the buffer's own .buffer property directly, as per https://stackoverflow.com/a/31394257/1375574. The Buffer constructor also takes an ArrayBufferView argument if you need to go the other direction.

Note that this will not create a copy, which means that writes to any ArrayBufferView will write through to the original Buffer instance.

From Buffer to ArrayBuffer:

function toArrayBuffer(buffer) {
  const arrayBuffer = new ArrayBuffer(buffer.length);
  const view = new Uint8Array(arrayBuffer);
  for (let i = 0; i < buffer.length; ++i) {
    view[i] = buffer[i];
  }
  return arrayBuffer;
}

From ArrayBuffer to Buffer:

function toBuffer(arrayBuffer) {
  const buffer = Buffer.alloc(arrayBuffer.byteLength);
  const view = new Uint8Array(arrayBuffer);
  for (let i = 0; i < buffer.length; ++i) {
    buffer[i] = view[i];
  }
  return buffer;
}

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.

Summary

Unless you need the ability to write/edit (using an ArrayBuffer), then Blob format is probably best.

Detail

I came to this question from a different html5rocks page., and I found @Bart van Heukelom's comments to be helpful, so I wanted to elevate them to an answer here.

I also found helpful resources specific to ArrayBuffer and Blob objects. In summary: despite the emphasis on Blob being immutable/"raw data" Blob objects are easy to work with.

Resources that compare / contrast ArrayBuffer vs Blob:

• Mutability
  • an ArrayBuffer can be changed (e.g. with a DataView)
  • a Blob is immutable
• Source / Availability in Memory
  • Quoting Bart van Heukelom:

  • An ArrayBuffer is in the memory, available for manipulation.
  • A Blob can be on disk, in cache memory, and other places not readily available

• Access Layer
  • ArrayBuffer will require some access layer like typed arrays
  • Blob can be passed directly into other functions like window.URL.createObjectURL, as seen in the example from OP's URL.
    • However, as Mörre points out you may still need File-related interfaces and API's like FileReader to work with a Blob.
• Convert / Generate
  • You can generate Blob from ArrayBuffer and vice versa, which addresses the OP's "Aren't both containers comprised of bits?"
  • ArrayBuffer can be generated from a Blob using the FileReader's readAsArrayBuffer method , or the async method const arrayBuffer = await blob.arrayBuffer() (thanks to @Darren G)
  • Blob can be generated from an ArrayBuffer as @user3405291 points out new Blob([new Uint8Array(data)]);, shown in this answer
• Use in Other Libraries
  • jsZip; (new JSZip()).loadAsync(...) accepts both ArrayBuffer and Blob: String/Array of bytes/ArrayBuffer/Uint8Array/Buffer/Blob/Promise
• How does protocol handle ArrayBuffer vs Blob
  • Websocket (aka WS / WSS)
    • Use the webSocket's binaryType property (could have values "arraybuffer" or "blob") to "control the type of binary data being received over the WebSocket connection."
  • XmlHttpRequest (aka XHR)
    • Use the xhr's responseType property to "to change the expected response type from the server" (valid values include "arraybuffer", "blob", and others like "document", "json", and "text")

    • the response property will contain the entity body according to responseType, as an ArrayBuffer, Blob, Document, JSON, or string.

Other helpful documentation:

• ArrayBuffer

The ArrayBuffer object is used to represent a generic, fixed-length raw binary data buffer. You cannot directly manipulate the contents of an ArrayBuffer; instead, you create one of the typed array objects or a DataView object which represents the buffer in a specific format, and use that to read and write the contents of the buffer.

• Blob

A Blob object represents a file-like object of immutable, raw data. Blob represent data that isn't necessarily in a JavaScript-native format. The File interface is based on Blob, inheriting blob functionality and expanding it to support files on the user's system.