Dot vs Bracket Notation

Dot notation is the default. It reads better, and it tells the reader and the type checker that the key is a known identifier. Use it whenever the property name is a valid JavaScript identifier and you know it at compile time.

Bracket notation is needed in four situations. The key is dynamic, so it is held in a variable. The key contains characters that are not valid in an identifier, such as a space or a hyphen. The key is a symbol rather than a string. Or the key is a reserved word in some contexts, where the bracket form is the clearer choice even though modern engines accept reserved words after a dot.

There is also a performance consideration that is smaller than it used to be. Modern engines compile both forms to roughly the same property access when the key is a literal string, so the old argument about bracket notation being slower no longer holds for constant keys. It is only noticeably slower when the key is a computed expression that the engine cannot treat as a fixed name, because the lookup cannot be cached as easily.

Style guidance for a team is simple: dot notation unless you have a reason not to. The reason is not really performance, it is readability and tooling. Bracket notation everywhere makes the code look dynamic when it is not, and it defeats autocomplete in editors.

Bracket notation is the answer, because the key inside the brackets is an ordinary expression that gets evaluated first. That expression can be a variable, a function call or the result of a concatenation.

const user = { name: "Ada", "favourite colour": "blue" };

// Dot notation for simple identifiers.
console.log(user.name);   // "Ada"

// Bracket notation for keys that are not valid identifiers.
console.log(user["favourite colour"]);   // "blue"

// A computed key from a variable.
const field = "name";
console.log(user[field]);   // "Ada"

// Optional chaining avoids a crash on a missing path.
const settings = { theme: { color: "dark" } };
console.log(settings?.theme?.color);      // "dark"
console.log(settings?.missing?.color);    // undefined - no crash
console.log(settings["missing"]?.color);   // undefined

The optional chaining operator is what makes dynamic access safe. When you write settings?.missing?.color, the whole chain short-circuits to the empty value as soon as it hits a null or missing step, and nothing after it is evaluated. The result is the empty value rather than a TypeError.

Note the difference between the two lines at the end. The first uses optional chaining on both steps, so a missing first property short-circuits. The second indexes with brackets first, which would throw if the property were missing, and only then uses optional chaining. If you are reading a nested value from data you do not control, use optional chaining at every step where a value could be missing.

One more thing to know. Bracket notation also works with symbols, which dot notation cannot. If a key is a symbol, you have to use the bracket form with the symbol itself rather than its description.