Using the JavaScript "with" is discouraged. It introduces code that cannot be optimized, but more importantly it is code that is hard to reason about. The body

Using the JavaScript "with" is discouraged. It introduces code that cannot be optimized, but more importantly it is code that is hard to reason about. The body of the with executes in a scope modified by an arbitrary object, determined at that point in the program's execution. To understand the semantics of a use of with, it is necessary to understand everywhere when and how the object that the with is acting on can change. See the tweet by Brendan Eich (inventor of JavaScript) on the with: https://twitter.com/BrendanEich/status/68001466471817216 https://twitter.com/BrendanEich/status/68001466471817216 From here on, this rest of this comment is probably of little interest, but for those curious about what I mean when I say "reason about" a program let me try to explain in more detail. Programming in an imperative language (i.e. not a functional programming language) involves a series of steps which make changes to the state of the program's data. We can't desk check interesting programs by working through all interesting steps by hand (or otherwise there is no point in having a computer do it); there are typically just too many steps and iterations. So how do programmers do it? One reasons about the state of a program by examining and understanding how it is affected by each statement. So, for example, in a while loop like: while x != y do x = f(x) end t = x the loop does something and even without understanding exactly what the side effects of f(x) are, we are able to reason about the properties of x once the program reaches the point where x is being assigned to t. We know that x equals y and so after the assignment statement we can assert that t, x and y are all equal. Now consider the same while loop with only a slight change: while x != y do x = f(x) end L: t = x Now the assignment of x to t has a label and can be the destination of a goto statement (I'm using an example from the bad old days when goto statements could take you anywhere in a program). What can be said about the relationship between t, x, and y after the assignment? It depends on anyplace in the code that can goto to label L. We can no longer reason about the code by examining it statically. We have to understand the global execution and when and where the goto can happen and what the value of x and y might be at each of these potential goto statements during the execution of the program. We've lost the ability to reason about the code in a systematic way by simply looking at it. We would have to consider every possible way the execution of the program could change x or y and then jump to L. Certain programming patterns make understanding programs difficult. Unbridled goto's were an early source of such problems. Now, most languages and programers restrict how they use goto to patterns that are safer because they don't make reasoning about the programs much more difficult. Dynamic scoping (around since the early days of LISP) makes reasoning about a program's state more difficult than lexical scoping; consequently, most programming languages now eschew dynamic scoping in favor of lexical scopes (that is scopes for variables determined by the structure of the source code rather than the dynamic call patterns during execution). The JavaScript "with" is deprecated because it can be applied to an object that is unknown until the program actually runs. The body of the with is executing in this dynamically determined scope so we can't really reason about what is going on while looking at the code.