This idea is neat, and the article does a good job of highlighting some of the potential evil and potential good of eval. However, as many other commenters have

This idea is neat, and the article does a good job of highlighting some of the potential evil and potential good of eval. However, as many other commenters have pointed out, it's far from a complete or trustable solution--and even if it's good enough for now, it may not be good enough for the JS of tomorrow (this language iterates bloody fast). Far better would be a capability-based sandbox API in the browser (like the Node.JS one: https://nodejs.org/api/vm.html#vm_vm_createcontext_sandbox_options https://nodejs.org/api/vm.html#vm_vm_createcontext_sandbox_o...) that also supports filters like "stack depth" to limit infinite recursion, and/or some sort of opcount to limit other nonterminating functions. Combine those two things, and you have at least a way to secure arbitrary code you want to eval. I think that most people with a real/non-insane need for such a service would be willing to pay a fair amount of performance (e.g. introducing an Erlang-esque reduction count idea to code inside the sandbox) to get it working safely. Mind you, even if that existed it'd be hard to use correctly; people would try to safe-eval code, fail, and open up over-promiscuous capabilities (just like redis: http://antirez.com/news/118 http://antirez.com/news/118), putting us back at square one. For many purposes, though, it would be a very interesting and powerful tool when wielded carefully.