how exactly does eval() keyword break compiler optimizations in javascript

function func1(str) {
  eval(str);
  newVar = 100;
  function func2() {
     console.log(bar);
     console.log(newVar);
  }
  func2();
}

func1("bar = 42;");

I've read that the eval() keyword should be avoiding because it cheats the lexical scope (which results in code running slower). With the context of the above example (or any other examples anybody has) i'm trying to understand what kind of compiler optimizations this might end up breaking.

Looking at the line newVar = 100; this variable too will be created by the engine (on the global scope) during the execution phase. I don't think this amounts to 'cheating' the lexical scope. Then whats the issue with eval("bar = 42;") which essentially does something similar? Hope the question is clear.

Solution

Because they're compiler optimizations, and the code passed to eval is almost obligatorely interpreted.

In your case the modern engines are probably smart enough to realize it's a string literal and optimize accordingly, but a new execution context is still created, and you waste a function call. Almost every single thing that an ordinary program does using eval, can be done without eval.

function func1(value)
{
  var bar = value;
  var newVar = 100;
  function func2() {
     console.log(bar);
     console.log(newVar);
  }
  func2();
}

func1(42);

EDIT: Actually, let's go deeper. On the code above, there is no possible state in which bar would be undefined when the console.log(bar); part of the code is reached. And it would always be a Number. Actually, it would always be 42. Assuming the engine has a perfect optimization algorithm, would the same hold true if the input from your eval'd code was dynamic, like for instance, coming from an AJAX reply or some form of user input? Not always. And optimizations always need to be SURE of the things they assume to cut down on final code.