Data structures

Programming languages all have built-in data structures, but these often differ from one language to another. This article attempts to list the built-in data structures available in JavaScript and what properties they have; these can be used to build other data structures. When possible, comparisons with other languages are drawn.

The ECMAScript standard defines six data types:

  • Number
  • String
  • Boolean
  • Null
  • Undefined
  • Object

In the following sections, we will see how these types can be used to represent data and be combined to implement more complex data structures.

Primitive values

All types except objects define immutable values. Specifically, strings are immutable (unlike in C for instance). We refer to values of these types are "primitive values." This is explained in more detail in the section on Strings below.

Booleans, null and, undefined

Within these types, four constants can be found: true, false, null, and undefined. Since these are constants, it is not possible to represent rich data (and data structures) with these.


According to the ECMAScript standard, there is only one number type which is the "double-precision 64-bit binary format IEEE 754 value", specifically there is no specific type for integers. In addition to being able to represent floating-point numbers, it has some symbolic values: +Infinity, -Infinity, and NaN (not-a-number).

Although a number often represents only its value, JavaScript provides some binary operators. These can be used to represent several Boolean values within a single number using bit masking. This is usually considered a bad practice, however, since JavaScript offers other means to represent a set of Booleans (like an array of Booleans or an object with Boolean values assigned to named properties) and bit masking often tends to make code more difficult to read, understand, and maintain. It may be necessary to use such techniques in very constrained environments, like when trying to cope with the storage limitation of local storage or in extreme cases when each bit over the network counts. This technique should only be considered when it is the last thing that can be done to optimize size.


Unlike in languages like C, JavaScript strings are immutable. This means that once a string is created, it is not possible to modify it. However, it is still possible to create another string based on an operation on the original string, for example, a substring of the original (by picking individual letters or using String.substr()) or a concatenation of two strings using the concatenation operator (+) or String.concat().

Beware of "stringly-typing" your code!

It can be tempting to use strings to represent complex data. They have a couple of nice properties:

  • It's easy to build complex strings with concatenation.
  • Strings are easy to debug (what you see printed is always what is in the string).
  • Strings are the common denominator of a lot of APIs (input fields, local storage values, XMLHttpRequest responses when using responseText(), etc.) and it can be tempting to only work with strings.

With conventions, it is possible to represent any data structure in a string. This does not make it a good idea. For instance, with a separator, one could emulate a list (while a JavaScript array would be more suitable). Unfortunately, when the separator is used in one of the "list" elements, then, the list is broken. An escape character can be chosen, etc. All of this requires conventions and becomes a maintenance burden which does not exist when the right tool for the right job is used.

It is recommended to use strings for textual data and symbolic data, but to parse strings and use the right abstraction for what it is supposed to represent otherwise.


In JavaScript, objects can be seen as a bag of properties. With the object literal syntax, a limited set of properties are initialized; then properties can be added and removed. Property values can be values of any type, including other objects which enables building complex data structures.

"Normal" objects, and functions

A JavaScript object is a mapping between keys and values. Keys are strings and values and be anything. This makes objects a natural fit for hashmaps. However, one has to be careful about the non-standard __proto__ pseudo property. In environment that supports it, '__proto__' does not allow to manipulate one property with such a name, but the object prototype. In context where it is not necessarily known where the string comes from (like an input field), caution is required: other have been burned by this. In that case, an alternative is to use a proper StringMap abstraction.

Functions are regular objects with the additional capability of being callable.


Arrays are regular objects for which there is a particular relationship between integer-key-ed properties and the 'length' property. Additionally, arrays inherit from Array.prototype which provides to them a handful of convenient methods to manipulate arrays like indexOf (searching a value in the array) or push (adding an element to the array), etc. This makes arrays a perfect candidate to represent lists or sets.


When considering representing dates, the best choice is certianly to use the built-in Date utility

WeakMaps, Maps, Sets

Non-standard. Likely to be standardized as part of ECMAScript 6.

These data structures take object references as keys. Sets represents a set of objects while WeakMaps and Maps associates a value to an object. The difference between Maps and WeakMaps is that in the former, object keys can be enumerated over. This allows garbage collection optimizations in the latter case.

WeakMaps, Maps and Sets could be implemented in pure ECMAScript 5, however, since objects cannot be compared (in the sense of "less than" for instance), lookup would necessarily be linear. Native implementation can have logarithmic to constant-ish lookups. Also, naive implementations of WeakMaps would not have the nice garbage collection properties.

Usually, to bind data to a DOM node, one could set properties directly on the object or use data-* attributes. This has the downside that the data is available to any script running in the same context. Maps and WeakMaps make easy to privately bind data to an object.


Non-standard. Likely to be standardized as part of ECMAScript 6.

Tags (1)

Edit tags

Attachments (0)


Attach file