With Statement

What a with statement does in JavaScript

A with statement temporarily places an object at the front of the scope chain, so property lookups can be written without repeating the object name. That can make code shorter, but it also changes how the engine resolves names and can make intent less obvious to readers and tools.

Because the construct alters identifier resolution, a name inside the block may resolve to a property of the target object instead of a local variable or outer binding. This is the core reason modern JavaScript style guidance generally avoids it: the same line of code can become harder to reason about, especially during refactoring.

Why it is hard to analyse safely

Static analysis and human review both become less reliable when scope is rewritten implicitly. A with block can hide where a value comes from, which makes it easier to introduce accidental shadowing, accidental global reads, or references that appear local but are actually dynamic property lookups.

That ambiguity is especially problematic in codebases that rely on tooling, minification, linting, or automated refactoring. The construct reduces the compiler and the reviewer’s ability to prove what a name means, so even small edits can have unintended effects.

When the construct changes program behaviour

The main behavioural risk is not just readability, but name collision. If the object being added to scope has a property with the same name as an existing variable, the lookup result can change depending on the block context, which can produce subtle bugs that are difficult to trace.

In practice, that means the same identifier may refer to different values depending on surrounding scope and runtime object shape. This is one reason the feature is considered fragile: the code’s meaning depends on both lexical structure and object contents.

Modern alternatives and coding style

Modern JavaScript code usually prefers explicit property access or destructuring, because both preserve clarity without rewriting scope rules. Those approaches make dependencies visible, help linting and code review, and avoid the hidden resolution semantics that make with statements difficult to maintain.

If a codebase already contains with statements, the safest approach is to remove them during cleanup or migration rather than continue expanding their use. The construct is widely treated as legacy JavaScript syntax, so new code should avoid it unless there is a very unusual compatibility reason.

Related resources from NHI Mgmt Group

• What do teams get wrong about the statement of applicability?
• How do you know if quantum preparedness is more than a policy statement?
• How should security teams write an ISO 27001 Statement of Applicability so it stands up in audit and internal review?
• Why does the Statement of Applicability matter so much in an ISO 27001 programme?