Hehe, you’re probably right about that, but you could script the live part with the api, and then get the eval part to update as you mentioned, and allow the user to play around at the same time. I'm sorry you didn't find it related.
And I have no doubt that's how it would be done, except that it turns out eval isn't actually necessary for a browser interactive REPL, which is pretty much all that developers need.
Straight-up eval() would be the most blatant case of a remote code execution vulnerability the web has ever seen. I don't think it's easy or even possible to build a foolproof sandbox out of eval(). And even then you open yourself to a denial of service since you cannot interrupt the eval().
Not exactly sure why you got downvoted. Perhaps people should actually say why they think eval is a bad idea.
My guess is it's something to do with cross site scripting. I can see advantages to using XMLHttpRequest in conjuction with eval in some cases, such as being able to monitor script download progress with the onprogress event.
That doesn't work (easily) in a function as eval only has the global context, not access to local variables (although you can do some hackery to make it work)
Removing eval wouldn't help— you could always just write a tiny interpreter to do the same thing. This is a problem in any Turing complete programming language (with Reflection), although JS makes it easier.
reply